AncalagonTotof a écrit 455 commentaires

Merci pour toutes ces réponses ! Je ne pourrai pas répondre à toutes individuellement malheureusement, j'ai procrastination …

Bon, si je résume correctement :

1) pour maîtriser Yocto, il faut maîtriser Yocto. OK, c'est clair ! find et grep comme seuls outils, c'est anecdotique …

2) le problème, c'est ma boite. Elle n'a aucune vision à long terme, ne sait même pas ce que c'est qu'un soft, et encore moins son dév, etc. Je vais pas vous faire la liste de tous les problèmes et des mauvais choix stratégiques, sauf à dire que justement, ils disent souvent "stratégie", mais ils confondent avec "objectif". Entre maintenant, et l'objectif, on va faire des réunions, et on changera d'avis en cours de route, et … Désolé, je crois que j'ai de plus en plus besoin d'un divan …

3) la prochaine fois qu'un Yocto me tombe dessus, je réponds merde, en principe, ça colle avec tout … Mais surtout parce qu'un "temps Yocto" ne peut pas être compris/envisagé par nos "décideurs"

4) merci spécial à M. Petazzoni. Free Electrons, pardon, Bootlin ;-) semble faire autorité. J'ai failli vous contacter pour un projet avant son abandon. Oui, je ressasse encore …

Ah, si, un dernier truc, on est vendredi, donc, sus à systemd !

C'est une vraie question : est-ce que vous avez connaissance de cas d'utilisation concret, ayant abouti à la réalisation, voire la commercialisation d'un produit, avec un OS construit avec Yocto ?

Pourquoi je demande ?

Je vais essayer de faire bref, ce qui indique généralement que ça va être confus ! Ou même pas vraiment bref … Bref …

J'ai utilisé Yocto dans plusieurs cas de figure, sans jamais concrétiser, ou en obtenant un résultat bancal, fragile. C'étaient des projets de R&D, ils n'ont pas aboutis pour diverses raisons, ça n'est pas grave (un peu quand même, pour l'amour propre, mais on s'en remet …).

Mais j'ai souffert avec ce truc, la vache !

En gros, de ce que j'en retire, c'est qu'il y a beaucoup de moyen d'arriver à un résultat bon, mauvais ou acceptable …
La doc officielle explique plein de choses, mais il est difficile de trouver la bonne méthode, ne serait-ce que pour ajouter un paquet au build. Qui peut me dire où je dois taper pour ajouter le package mpg123 par exemple ? Rien que pour ça, j'ai déjà trouvé plusieurs méthodes …

Et les outils qui m'ont été les plus utile sont find et grep, souvent combinés en find . -type f -exec grep -Hn <truc> "{}" \;

C'est d'un lourdingue, naudidju ! Au bout de 100 ou 200 find/grep, ça fatigue … Et Yocto, c'est gros, non, gigantesque. Un build peut faire grimper une arborescence à facilement plus de 50 ou 100 Go. Un find/grep là-dedans … Brrrr …

J'ai pratiqué en ciblant du ATmel SAMA5D2, du i.MX6 et du 7, mais je vais décrire un cas sur Raspberry Pi. Peu importe le projet, l'objectif était d'avoir un OS avec affichage graphique (Qt), écran tactile et quelques communications série et I2C avec le monde extérieur.

• étape 1 : Raspbian. Bien au début, un peu pénible pour Qt (une tentative en direct, une autre avec QTRPI), bizarre quant à la config du tactile et de son orientation portrait (2 R-Pi, 2 Rasbian identiques, orientation OK sur l'une, NOK sur l'autre). On laisse tomber Raspbian.

• étape 2 : Yocto. Cool, c'est du R-Pi, c'est méga répandu, ils en ont vendu des myiards, ça va rouler tout seul. Eh beh nan. Grosse galère pour Qt et d'autres bricoles. Vite abandonné.

• étape 3 : Buildroot. Magnifique ! Approche directe, ça se configure quasiment comme un kernel (make menuconfig; recherches faciles avec /) la plupart du temps, la seule et unique doc ne fait que 130 pages. J'ai très vite obtenu mon premier OS fonctionnel. Mais surtout, les retouches successives pour ajouter tel ou tel package manquant se sont faite naturellement, sans chercher pendant des heures (ou des jours; si, si, c'est possible avec Yocto !). J'ai besoin d'un truc, ça me paraîtrait logique que ça marche comme-ci ou comme-ça, et effectivement, ça se passe comme prévu. La chaîne de cross-compilation s'est faite toute seule, et a fonctionné nickel sur la bécane du collègue. Au final, un OS qui affiche une image quasi instantanément, une petite animation au démarrage des services et notre application qui arrivait très vite avec quasiment rien pour encombrer le boot. Et nos devices gérés correctement, jusqu'à l'écran en portrait (sur les deux exemplaires de R-Pi à l'identique, hein !).

Au passage, pour Yocto, selon le fabricant du SoC, selon le fabricant du SoM, et selon l'âge du capitaine, on récupère des choses, avec la commande repo initiale, rarement organisées de la même manière, quand ça n'est pas carrément un conteneur Docker !

Alors, il se dit que les deux ont leur intérêt. Par exemple, Yocto est plus indiqué pour faire une gamme de produits ou pour pouvoir réutiliser les layers d'un projet sur l'autre. OK, probablement, mais avant de passer à un nouveau projet, il faudrait terminer le premier ! Plus sérieusement, je commence à sérieusement douter : ça fait des dizaines d'années qu'on me parle de ré-utilisabilité, mais j'en ai jamais vraiment vu …

Tandis qu'avec Buildroot, tout est direct au but, logique et sans détour.

D'où ma question initiale : vraiment utilisé, Yocto ?

Oh, je sais qu'on est pas vendredi, mais je précise quand même : Buildroot, c'est avec un bon vieil /etc/inittab des familles, et c'est sans systemd !!!

Là maintenant, je n'ai aucune problème pour récupérer le package et le décompresser à la main.
Il y avait peut-être un soucis entre chez toi et les serveurs au moment du problème.

Autre possibilité : j'ai récemment testé Pi-Hole sur un R-Pi. Tout allait bien jusqu'à une mise à jour de la Raspbian.
Il m'a fallu un moment pour déterminer que la carte µSD, a priori de qualité pourtant (Samsung ?), avait à moitié rendue l'âme : accessible en lecture seule. Mon Pi-Hole tourne dans une VM maintenant …

Est-ce que le problème ne serait pas plutôt que ce système de carte (e-carte bleue ?) n'autorise qu'un et un seul usage de la carte temporaire ?
On est d'accord, celui qui pose le vrai problème, c'est le commerçant.

Hello,

J'ai pas lu tous les commentaires (trop dur au p'tit déj …).
Est-ce que quelqu'un a pensé à te dire d'arrêter de coder comme ça ?
Parce que ça te fatigue déjà.
Et pour les autres, tu te rends pas compte de ce que c'est. Ça nous fout une angoisse …

Logiquement, l'utilisateur sous lequel se lancent les scripts (root ici ?) reçoit des mails si ces scripts écrivent sur la sortie standard (stdio, avec echo par exemple) ou d'erreur (stderr, en cas de problème d'exécution).
Est-ce que root a reçu des mails ?

Faux ! J'en ai plein en .sh ! Et ça fonctionne très bien !
Plutôt un problème d'environnement comme évoqué plus haut je pense.

Hello,

C'est l'histoire d'un logiciel de traitement de fichier RAW nommé Nikon Capture NX2 (CNX2) pour Mac dans ce cas précis.

OK, c'est du soft proprio, mais bon, des fois, faut faire avec. Oui, je connais DarkTable et RawTherapee.

Tout allait très bien sur mon MacBook Pro de 2013/2014, jusqu'au jour où, à force de faire le con, j'ai pété l'OS. Oui, un Mac OS, c'est fragile. Pas comme un windows, mais ça fini par se déglinguer aussi.
Donc, j'ai refais une installation. Et là, plus moyen d'installer CNX2. Buh ??? Pourquoi ???

Hypothèse : c'est à cause des versions de l'OS. Mon Mac m'a été livré en version 10.9.xx.
CNX2 requiert un Mac OS en 10.411 ou 10.5.7 minimum.

Donc au début, ça s'installe, normal.

Ensuite, j'ai fait les mises à jour vers 10.10, 10.11, etc. Et la réinstallation de l'OS s'est faite avec la dernière version dispo.
L'installation de CNX2 vérifie la version de l'OS avant d'aller plus loin, et donc : 10.10 < 10.5, refus d'installer.

Si,si.

Tout simplement parce que ces pignoufs ont codé leur versions en string et pas en numérique !
Du coup, oui, "10.10" < "10.5" parce que "10.1" < "10.5".

Ah ben bravo, 20/20 !

Récemment, j'ai encore réinstallé l'OS, mais après avoir tout rincé de chez rincé. Faut reconnaître, c'est sympa de voir sa machine booter sans rien, et aller cherche le setup de l'OS sur le Net. Ça serait top de voir un PC vierge proposer l'installation de Linux, Windows ou macOS. Voire un triple boot … Mais passons.
Bonne surprise cette fois, c'est l'OS d'origine qu'il me télécharge, en 10.9 donc.
Et à nouveau, j'ai pu installer CNX2.

CQFD ?

Bref, tout ce blabla inintéressant pour dire : fézé gaffe avec les numéros de version, c'est un sujet qui paraît innocent, mais qui peut foutre une merde noire …

Exemple avec ce que j'ai sous le coude. Parce que sous UNIX, tout est fichier, fdisk peut prendre directement l'image en paramètre :

# fdisk -l 2019-07-10-raspbian-buster-lite.img
Disk 2019-07-10-raspbian-buster-lite.img: 2 GiB, 2197815296 bytes, 4292608 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x17869b7d

Device                               Boot  Start     End Sectors  Size Id Type
2019-07-10-raspbian-buster-lite.img1        8192  532480  524289  256M  c W95 FAT32 (LBA)
2019-07-10-raspbian-buster-lite.img2      540672 4292607 3751936  1.8G 83 Linux

Comme évoqué plus haut, on voit effectivement les deux partitions d'une image pour Raspberry Pi :

• une de type FAT32 contenant kernel, modules, configuration, etc
• une de type Linux avec le root filesystem (/) et l'OS

mount monter ces partitions, c'est très simple. On commence par créer deux répertoires pour le montage :

# mkdir p1 p2

Premier montage :

# mount -o loop,offset=$((8192*512)) 2019-07-10-raspbian-buster-lite.img p1

Vérification :

# l p1
total 39510
-rwxr-xr-x 1 root root   23946 Jul  8 15:02 bcm2708-rpi-b.dtb*
-rwxr-xr-x 1 root root   24205 Jul  8 15:02 bcm2708-rpi-b-plus.dtb*
-rwxr-xr-x 1 root root   23723 Jul  8 15:02 bcm2708-rpi-cm.dtb*
-rwxr-xr-x 1 root root   23671 Jul  8 15:02 bcm2708-rpi-zero.dtb*
-rwxr-xr-x 1 root root   24407 Jul  8 15:02 bcm2708-rpi-zero-w.dtb*
-rwxr-xr-x 1 root root   25293 Jul  8 15:02 bcm2709-rpi-2-b.dtb*
-rwxr-xr-x 1 root root   26463 Jul  8 15:02 bcm2710-rpi-3-b.dtb*
-rwxr-xr-x 1 root root   27082 Jul  8 15:02 bcm2710-rpi-3-b-plus.dtb*
-rwxr-xr-x 1 root root   25261 Jul  8 15:02 bcm2710-rpi-cm3.dtb*
-rwxr-xr-x 1 root root   40284 Jul  8 15:02 bcm2711-rpi-4-b.dtb*
-rwxr-xr-x 1 root root   52296 Jun 24 17:21 bootcode.bin*
-rwxr-xr-x 1 root root     190 Jul 10 02:21 cmdline.txt*
-rwxr-xr-x 1 root root    1735 Jul 10 02:08 config.txt*
-rwxr-xr-x 1 root root   18693 Jun 24 17:21 COPYING.linux*
-rwxr-xr-x 1 root root    3030 Jul  9 16:07 fixup4cd.dat*
-rwxr-xr-x 1 root root    6068 Jul  9 16:07 fixup4.dat*
-rwxr-xr-x 1 root root    9146 Jul  9 16:07 fixup4db.dat*
-rwxr-xr-x 1 root root    9148 Jul  9 16:07 fixup4x.dat*
-rwxr-xr-x 1 root root    2649 Jul  8 15:02 fixup_cd.dat*
-rwxr-xr-x 1 root root    6724 Jul  8 15:02 fixup.dat*
-rwxr-xr-x 1 root root    9802 Jul  9 16:07 fixup_db.dat*
-rwxr-xr-x 1 root root    9798 Jul  9 16:07 fixup_x.dat*
-rwxr-xr-x 1 root root     145 Jul 10 02:21 issue.txt*
-rwxr-xr-x 1 root root 5299792 Jul  8 15:02 kernel7.img*
-rwxr-xr-x 1 root root 5600464 Jul  8 15:02 kernel7l.img*
-rwxr-xr-x 1 root root 5017104 Jul  8 15:02 kernel.img*
-rwxr-xr-x 1 root root    1494 Jun 24 17:21 LICENCE.broadcom*
drwxr-xr-x 2 root root   14848 Jul 10 02:07 overlays/
-rwxr-xr-x 1 root root  762880 Jul  9 16:07 start4cd.elf*
-rwxr-xr-x 1 root root 4716552 Jul  9 16:07 start4db.elf*
-rwxr-xr-x 1 root root 2759172 Jul  9 16:07 start4.elf*
-rwxr-xr-x 1 root root 3672712 Jul  9 16:07 start4x.elf*
-rwxr-xr-x 1 root root  685412 Jul  9 16:07 start_cd.elf*
-rwxr-xr-x 1 root root 4854088 Jul  9 16:07 start_db.elf*
-rwxr-xr-x 1 root root 2878052 Jul  9 16:07 start.elf*
-rwxr-xr-x 1 root root 3791560 Jul  9 16:07 start_x.elf*

Seconde partition :

# mount -o loop,offset=$((540672*512)) 2019-07-10-raspbian-buster-lite.img p2

Vérification :

# l p2
total 88
drwxr-xr-x  2 root root  4096 Jul 10 02:08 bin/
drwxr-xr-x  2 root root  4096 Jul 10 02:20 boot/
drwxr-xr-x  4 root root  4096 Jul 10 02:03 dev/
drwxr-xr-x 80 root root  4096 Jul 10 02:21 etc/
drwxr-xr-x  3 root root  4096 Jul 10 02:07 home/
drwxr-xr-x 16 root root  4096 Jul 10 02:09 lib/
drwx------  2 root root 16384 Jul 10 02:20 lost+found/
drwxr-xr-x  2 root root  4096 Jul 10 02:03 media/
drwxr-xr-x  2 root root  4096 Jul 10 02:03 mnt/
drwxr-xr-x  3 root root  4096 Jul 10 02:07 opt/
drwxr-xr-x  2 root root  4096 Jun  6 17:42 proc/
drwx------  2 root root  4096 Jul 10 02:03 root/
drwxr-xr-x  4 root root  4096 Jul 10 02:03 run/
drwxr-xr-x  2 root root  4096 Jul 10 02:09 sbin/
drwxr-xr-x  2 root root  4096 Jul 10 02:03 srv/
drwxr-xr-x  2 root root  4096 Jun  6 17:42 sys/
drwxrwxrwt  2 root root  4096 Jul 10 02:21 tmp/
drwxr-xr-x 10 root root  4096 Jul 10 02:03 usr/
drwxr-xr-x 11 root root  4096 Jul 10 02:03 var/

Explication :

L'option loop permet de monter ce genre d'image (ça pourrait être une ISO de CD, DVD ou Bluray aussi).
L'option offset, comme sa traduction l'indique, permet un décalage d'un certain nombre d'octets. Ici, on sait que les partitions commencent à 8192 et 540672, et que c'est exprimé en secteurs, qu'un secteur fait 512 octets, et donc, on fourni la multiplication grâce à $((<debut> * <nb octets par secteur)).

NB : je maîtrise mal loop & cie, et j'ai du "démonter" p1 avant de monter p2, suite à ce message d'erreur :

mount: /home/Misc/RaspberryPi/RaspBian.images/2019-07-10-raspbian-buster-lite.img: overlapping loop device exists

Tout ce que je sais, c'est qu'il existe un nombre limité de device loop possible et que c'est paramétrable (option du module, de mémoire).
Ici, pour je ne sais quelle raison, j'ai probablement atteint la limite. Limite à 1 semble-t-il …
Je ne vais pas le montrer ici, mais mount -o loop ... cache en fait un losetup suivit d'un mount. On pourrait décomposer les deux et peut-être éviter ce message d'erreur.

NB2 : le l de l p1 et l p2 est un alias que je me refais partout :

alias ls='ls -AF --color=auto'
alias l='ls -l'

Ptit joueur ! Ça fait un moment que j'ai une 7, à 1133 jours d'uptime, à virer et réinstaller chez eux. Trop vieux pour tenter une upgrade … Mieux vaut repartir sur du neuf !

Ah OK, j'avais pas vu la feinte !

[oh, ma réponse d'hier n'est pas passée ? Je la refais]

Oui, c'est tout à fait normal.
L'expression $(find * -maxdepth 0 -type f) est entre guillemets, et de ce fait, elle constitue un et un seul paramètre du for.
f prend donc une et une seule valeur, d'où un seul tour de boucle et un seul message "fin de ligne".

Problème : si tu supprimes les guillemets, tu retombes sur le problèmes espaces dans les noms de fichier. Chaque espace divisera le nom en deux et créera un paramètre supplémentaire au for là où il ne faudrait pas.

On en revient aux solutions à base de read et de while.

Pourquoi s'acharner sur le for sinon ? Je ne l'utilise quasiment jamais, cette limitation est trop contraignante.

[Complément 1]
Toutes ces formes d'écriture pallient au problème du for. Le for reçoit les paramètres après interprétation par le shell, et si ces paramètres comportent des espaces, ils deviennent deux ou plusieurs paramètres du for.

[Complément 2]
La version avec fichier temporaire présente l'inconvénient du … fichier temporaire ! Mais, dans certains cas, le résultat du find peut être utile à plusieurs boucle indépendantes, et donc, ce fichier temporaire permet d'exécuter ce find une fois pour toutes

Attention, j'écris ça de tête, sans vérifier.

D'abord, une solution simple mais bourrin et pas sans poser problème :

find ... | while read truc1 truc2 ... trucn
do
    ...
done

Le problème ? Si une variable est initialisée hors de la boucle, elle ne peut pas être modifiée dans cette boucle :

v=1
find ... | while read truc1 truc2 ... trucn
do
    v=$((v+1))
done
echo $v

affichera 1, quelque soit le nombre de tour de boucle, car le while est à droite d'un pipe ('|'), et s'exécute donc dans un shell fils.
Pour que le while reste dans le même shell, et toujours en étant bourrin :

v=1

find ... > /tmp/fichierIntermediaire

while read truc1 truc2 ... trucn
do
    v=$((v+1))
done < /tmp/fichierIntermediaire
echo $v

Cette fois, v va changer en fonction du nombre de lignes dans le fichier temporaire.

Pour éviter ce fichier temporaire, il faut utiliser quelque chose du genre :

v=1

while read truc1 truc2 ... trucn
do
    v=$((v+1))
done < <(find ...)
echo $v

C'est surtout ici que j'ai un doute sur la syntaxe. Mais si erreur il y a, on a l'idée.

De mon temps, c'était du 68000 ! Et puis j'ai fait un peu de 8086 … Que c'est moche …

Bref …

Pour la petite histoire, en embarqué, quand il s'agit de coller au plus près à l'architecture d'un microcontrôleur (Atmel, STM8 ou 32, Microchip PIC …), il est fréquent de "packer" à 1, histoire que tel champ corresponde à tel registre du CPU (sans trop rentrer dans les détails).

Et pour revenir au 68000, je me rappelle vaguement que tout était autorisé, y compris utiliser des adresses impaires, voire non multiples de 4, mais avec un surcoût à l'exécution. C'était pas gratuit …
Ça ne l'est toujours pas je suppose, ça fait des dizaines d'années que j'ai pas ouvert un bouquin d'assembleur de CPU.

<mode dystopie>Imaginez un peu, si IBM avait choisi Motorola à la place de Intel, fin des 70s, début des 80s … Le premier IBM PC avec un 68000 ! Le beau rôle ! Même pas de EMM386 ! Et le mauvais à Apple avec ses pauvres Apple ][ à base de 8088/8086 !</mode dystopie>
<mode réaliste>Le 68000 était pas sorti il me semble.</mode réaliste>

Il nous faudrait une "photo" de la "scène du crime" !

Dans une console, probablement en tant que root pour que ça fonctionne, il nous faudrait au moins ça :

fdisk -l

pour lister les disques et leurs partitions. Et ensuite :

df -h /

Pour savoir quelle est la partition '/', le root filesystem.
Ça permettra de savoir où tu as installé ton Linux déjà.

Autre possibilité : utiliser un outil graphique comme gparted.

Oui, peu probable qu'ils aient changé ta config.
Je ne suis pas expert, mais je vois un problème potentiel sur le chemin du retour des paquets. Encore une fois, super pas certain de moi.
Pour être exact, -T, c'est

Use TCP SYN for probes

Je pense que c'est un peu plus subtil que juste utiliser TCP. Ça a un rapport avec la façon dont s'établit une connexion TCP (SYN, ACK, etc. Je ne connais pas ça par cœur).

Un autre test à faire :

# telnet smtp.free.fr 587
Trying 212.27.48.4...
Connected to smtp.free.fr.
Escape character is '^]'.
220 smtp6-g21.free.fr ESMTP Postfix

Ça bloque aussi ?

Bon, ça m'étonnerait que ça vienne de là, vu que c'est dans le sens sortant.
Mais depuis un bon moment, Free triche.

Encore que je ne connaisse pas bien le mécanisme impliqué par l'option -T. Peut-être que ça vient de là. Tu as essayé sans ?

En tout cas, si c'est ça, ça peut venir de chez Free. Face à la pénurie d'adresse IPv4, Free "divise" une adresse en 4 blocs de ports. Pour une adresse IP, 4 clients se partagerons une plage de ports, soit 65536 (à un ou deux près, hein, zéro, toussa) divisé par 4 : 0 à 16383.

Le plus chanceux aura les ports de 0 à 16383.
Le second client aura les ports de 16384 à 32767, mappés sur 0 à 16383.
Le troisième de 32768 à 49151 et le dernier de 49152 à 65535, toujours mappés sur 0 à 16383.

On se fait enfumer des 3/4 des ports !

La solution : demander (via l'interface Web il me semble) une IP fixe, qui implique ce que Free appelle "IP Full Stack". En clair, une fois l'IP figée, on a droit à la totalité des ports, de 0 à 65535.

Quoi qu'il en soit, chez moi, ça donne ça :

# traceroute -p 587 -T  smtp.free.fr
traceroute to smtp.free.fr (212.27.48.4), 30 hops max, 60 byte packets
 1  192.168.0.254 (192.168.0.254)  0.156 ms  0.288 ms  0.518 ms
 2  194.149.164.60 (194.149.164.60)  6.149 ms  6.504 ms  6.505 ms
 3  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  6.870 ms  7.207 ms  7.211 ms
 4  bzn-9k-2-sys-be2000.intf.routers.proxad.net (194.149.161.242)  6.830 ms  6.807 ms  6.818 ms
 5  smtp.free.fr (212.27.48.4)  6.427 ms  6.429 ms  6.428 ms

Un traceroute simple donne :

# traceroute smtp.free.fr
traceroute to smtp.free.fr (212.27.48.4), 30 hops max, 60 byte packets
 1  192.168.0.254 (192.168.0.254)  0.213 ms  0.202 ms  0.532 ms
 2  * * *
 3  bzn-9k-4-be1004.intf.routers.proxad.net (78.254.249.2)  6.841 ms  7.300 ms  7.301 ms
 4  bzn-9k-2-sys-be2000.intf.routers.proxad.net (194.149.161.242)  6.555 ms  6.775 ms  6.516 ms
 5  smtp.free.fr (212.27.48.4)  6.152 ms  6.123 ms  6.130 ms

Aucun soucis particulier.

Le problème de vient pas du casque, ou du bonhomme, mais de l'open space : c'est une calamité.
Dans ma boite, la filiale dans laquelle j'étais a réintégré la maison mère. Une petite centaine de personnes ajoutées aux 6 ou 700 déjà présentes, réparties dans un ancien magasin/entrepôt reconverti en open space.
C'est bruyant en permanence. Y'a des réunions sauvages dans les "couloirs" (comprendre à côtés des bureaux et des gens qui y travaillent).
Et on nous a vendu l'open space comme étant un "espace d'échange". Tu parles. Je ne sais même pas qui sont les personnes à 3 mètres de moi ni ce qu'elles font …

Bref. Si il faut parler technique : moi, c'est Sony MDR 1000X, avec et sans musique selon l'humeur. C'est un bon (et cher) modèle, mais on fait mieux de nos jours.

Enfin, pour rester au courant de ce qui se passe au taff … Je suis mal placé, j'ai le même problème. C'est parce que je ne bois pas de café; c'est beaucoup là où s'échangent les infos. Reste radio-moquette, mais faut une bonne station à capter …

Si elle existe, c'est une fonctionnalité du casque, pas du côté Linux.

Un module Bluetooth qui permet le Share est capable d'être client d'une source, et en même temps, de se présenter comme source pour un autre appareil client. Le flux A2DP peut être prolongé de proches en proches, mais en ajoutant une latence à chaque nœud.

Cette méthode, par contre, est transparente et ne nécessite pas d'avoir les mêmes casques sur toute la chaîne.

Hello,

À ma connaissance, le problème vient plus de la source que des casques. La source doit être capable de gérer plusieurs connections vers plusieurs sink (c'est le terme habituel pour les destinataires des flux). Et c'est super rare. Pour que ça marche bien, il faudrait quasiment un double module (deux fois le même hardware).

Une première possibilité pourrait venir du BT Broadcast. Mais je ne crois pas que ce soit répandu, et encore moins standardisé.
La seule info un peu récente que j'ai concerne Microchip et sa solution une source vers multiple sinks. Mais, bien entendu, si la puce source et les puces sink ne sont pas des Microchip avec le bon firmware, c'est mort, vu que le protocole entre les intervenant est propriétaire.

Peut-être que la solution share conviendrait dans ton cas. L'idée, c'est que tu connectes ton linux au premier casque, et ensuite (ou avant ?) le premier casque au second. Les flux seraient donc PC -A2DP-> Casque 1 -A2DP-> Casque 2. Problèmes :
- si ça marche, il y a une latence. Le casque 2 sera toujours en retard sur le 1.
- faut que au moins le casque 1 dispose de la fonctionnalité, forcément

Sinon, t'as pensé à des liaisons filaires ? ;-)

C'est oublier un peu vite les quelques restrictions aux libertés et les coups de 49.3 !

Déjà, je dirais que la taille de la pile, ben ça dépend … Dans un contexte desktop, oui, possible. Mais ça risque fortement de dépendre aussi du langage, du compilateur/linker, et pour finir, des paramètres de ces derniers. La taille de la pile fait partie de ces paramètres, plus ou moins cachés selon l'environnement que tu utilises. Il me semble aussi que le principe le plus courant est d'avoir une pile de taille limitée, ce qui conduit à un stack overflow quand tu essayes de la dépasser. Mais peut-être qu'il existe d'autre contexte où la taille de la pile, c'est la mémoire qui reste ?
Quant à l'embarqué, quand tu n'as que quelques ko a utiliser méticuleusement …

Sur le schéma, entre le heap et la stack, c'est du … rien !
Tu consommes de la stack en faisant des appels de fonction (attention aux appels récursifs) et en déclarant des variables locales.
Tu consommes du heap en faisant des allocations dynamiques (malloc & cie, new en C++).

Forcément, trop de l'un et/ou de l'autre, c'est mauvais pour la santé du process …

Est-tu certain déjà qu'un sub, un not, ou autre, s'exécute en un seul cycle ?
Ça fait longtemps que je n'ai pas mis le nez là-dedans, mais j'en été resté à une instruction = plusieurs cycles.
Par contre, il existe tout un tas d'optimisations (pipeline, etc) qui permettent de paralléliser plus ou moins, genre, commencer l'exécution de l'instruction suivante alors que celle en cours n'est pas terminée.

NB: le 8086 est très loin aussi, mais est-ce que l'instruction sub existe vraiment ?… Sinon, c'est normal qu'il traduise par un négation puis une addition.

Salut, alors, on a la flemme de faire ses exos soit même ?
Si vraiment tu ne trouves pas, la solution est peut-être là