Yuul B. Alwright a écrit 156 commentaires

Le titre que tu utilise pour ton lien possède une ambiguïté.

On ne sait pas si :
- tu prétends que l'utilisation de l'Open Source par Element est remis en question
- tu fait une injonction à ce que tout le monde doivent remettre en question l'utilisation du modèle Open Source

Que souhaites-tu nous dire ? Car de ce que j'ai vu, le lien n'a pas ce titre.

Ce procédé, que tu utilises, est sale.

Prétendre, sans preuve, que la position avec laquelle tu es en désaccord est forcément une rengaine vide, afin d'essayer de la décrédibilisé avant même que les personnes tenant cette position ne puissent donner le moindre argument.

J'ai complètement oublié comment ce procédé s’appelle, mais c'est sale. Très sale.

Il n'y a aucune nécessité de s'excuser, ce sont des choses qui
arrivent. On est toutes et tous humain.

J'ai aussi connu une situation vraiment moche, à cause d'une
entreprise. C'était au point où être assis devant un ordinateur me
donnait envie de vomir. J'ai dut me débrouiller tout seul pour régler
ça, tout en restant "productif pour l'entreprise". Résultat, ça s'est
pas bien terminé. Burnout, licenciement et précarité. Et encore
aujourd'hui, j'ai l'impression de pas être légitime dans tout ce que
je fais, de ne rien valoir. Je ne souhaite ça à personne.

Prends du temps pour toi, concentre toi sur ta santé. Pour toi, pas
pour quelqu'un d'autre. Et prends toute l'aide que tu pourra trouver.
Je déconseille d'être seul pour ce genre de situation.

Le problème n'est pas que ces personnes aient respecté la licence. Mais plutôt qu'ils ou elles laissent croire qu'il s'agit d'une release officielle et aussi croire que l'argent va à l'équipe derrière le jeu.

Après, les personnes qui publient sur steam font aussi un travail. Un travail de publication. Et en soit, payer le travail de publication me semble aussi juste que de payer le travail de développement. Mais laisser planer le doute, en faisant croire que payer sur steam rémunère toute l'équipe, c'est moche.

La meilleur solution aurait été de contacter l'équipe derrière 0 A.D. et de trouver un arrangement. Partager le revenu de ces ventes.

Quel est votre éolienne préférée ?

Éolienne ? Éoliennes ? Éolienne 3 ? Éolienne: Resurrection ?

Venant de réaliser un travail avec du Lua, je comprends l'envie d'utiliser autre chose.

Désolé, pas pu résister.

Normalement, le système d'autorisation ne concerne-t-il pas uniquement la connexion PCIe du Thunderbolt ?
Il me semblait que les bus USB et DisplayPort du Thunderbolt ne l'utilisent pas.

Comme je l'ai précisé dans un commentaire plus haut, exécuter la commande "boltctl list" a détecté la sortie HDMI de l'adaptateur Thunderbolt HDMI.
Mais une fois l'adaptateur connecté et l'HDMI détecté, la commande "boltctl list" n'indique aucun périphérique.
Je présume que les sorties vidéos de l'adaptateur utilisent directement le bus DisplayPort.
Je sais qu'il existe des cartes graphiques externes qui utilisent le bus PCIe. Mais ce n'est pas le cas de mon adaptateur.

L'écran était déjà allumé quand j'ai connecté l'HDMI.

Alors, en essayant d'avoir plus d'information, j'ai connecté l'adaptateur Thunderbolt HDMI et j'ai exécuté la commande "boltctl list".
Résultat: La sortie HDMI a été détectée.

Il est à noter que l'adaptateur possède plusieurs interfaces:
+ 2 interfaces USB
+ 1 interface VGA
+ 1 interface HDMI
+ 1 interface Ethernet
+ 1 entrée pour l'alimentation
+ 1 connecteur Thunderbolt mâle, qui se connecte au PC

Lorsque je connecte l'adaptateur au PC, seul l'interface HDMI n'est pas détectée automatiquement.
Toutes les autres interfaces sont détectée et fonctionnent parfaitement.

Il y a donc un bug sur la détection de la sortie HDMI. Je dois trouver quel composant s'en occupe pour ouvrir un rapport de bug.
Est-ce le Kernel ou un autre outil qui s'occupe de détecter les périphériques Thunderbolt ?

Merci pour cette proposition.

Je ne cherchais pas à rendre le serveur web publique.
Juste à le rendre accessible via l'interface Wifi du serveur où il tournait.

Alors, j'ai finalement trouvé où était le problème: L'interface Wifi et Ethernet ne sont pas dans la même zone du par-feu.

Quand j'ai ouvert le port utilisé par le serveur web, je l'ai fait pour la zone par défaut du par-feu.
Comme l'interface Ethernet se trouve dans cette zone, je pouvais joindre le serveur web via cette interface.
Mais l'interface Wifi, qui servait de point d'accès, se trouvait dans la zone nommée "nm-shared".

Donc, pour rendre mon serveur web accessible sur l'interface Wifi, j'ai dut ouvrir le port 8000 pour la zone "nm-shared".

Pour cela, j'ai exécuté ces 2 commandes:

sudo firewall-cmd --zone=nm-shared --add-port=8000/tcp
sudo firewall-cmd --zone=nm-shared --permanent --add-port=8000/tcp

Merci pour les proposition.

J'ai finalement réglé le problème.

Le code assembleur généré par GCC pour une des lignes de mon code C était complétement aux fraises et c'est ce qui produisait un reset du CPU.

Par contre, je ne sais pas pourquoi GCC générait ce code. Il a cessé dès que j'ai modifié mon code ailleurs que sur la ligne concernée.

Merci pour ta réponse. :)

Mon objectif n'est pas d'être productif, mais d'écrire un firmware from scratch.
Je me suis basé sur la vidéo de Nikolay Kondrashov qui a écrit un firmware from scratch pour un autre uC avec la même architecture:
https://media.ccc.de/v/ASG2019-161-microcontroller-firmware-from-scratch

Avant de commencer, j'ai bien lut le manuel du uC pour savoir comment il démarre, qu'est-ce qui est actif ou pas au démarrage, qu'est-ce qu'il faut initialiser.
Comme dit dans une de mes réponses plus haut, j'arrive à écrire et lire dans les registres depuis OpenOCD. Donc le problème ne semble pas venir d'une composant non initialisé, mais plutôt du code généré.

Pour les instructions Thumb: J'ai précisé manuellement à GDB que les instructions sont du Thumb avec la commande set arm force-mode thumb.
Mais il affiche toujours <UNDEFINED> instruction: 0xf590601a.

Merci pour ta réponse. :)

Mon objectif est justement de partir d'une feuille blanche.
J'ai comparé avec le travail d'autre personnes mais je n'ai pas trouvé de différence majeur sur la partie compilation ou initialisation.

Le LPC1769 a comme avantage d'être très simple:
* Au reset, il récupère l'adresse du sommet de la stack à l'adresse 0x0000 et la copie dans le registre correspondant
* Il récupère ensuite l'adresse de la première instruction à exécuter à l'adresse 0x0004 et la copie dans le registre correspondant
* Il commence l'exécution
* Au reset, une mémoire, la Boot ROM, est mappée à l'adresse 0x0000:
* Le code qui s'y trouve s'exécute puis "re-mappe" la flash à l'adresse 0x0000
* Le code présent sur la flash prend le relais (chargement de l'adresse du sommet de la stack et de la première instruction)
* Les GPIO sont par défaut alimenté, connecté à une horloge active et connecté à une pin physique du uC

D'ailleurs, si l'écriture dans les registres depuis du code reset le CPU, avec OpenOCD j'arrive à lire et écrire directement dans les registres sans problème.

Ce qui me fait dire que le problème vient du code assembleur généré par GCC. Mais je ne trouve pas pourquoi.

Merci pour ta réponse. :)

Avec GCC, la compilation pour l'architecture Cortex-M3 ne supporte que le mode Thumb.

J'ai regardé à quoi ressemblent les Makefiles utilisés par l'IDE officiel: Même en reprenant les options en lien avec la compilation le CPU reset toujours au même endroit.

Merci beaucoup pour vos réponses. Je vais regarder plus en détails les propositions.

Merci beaucoup ce travail. ;)

J'en profite pour partager mon expérience sur l'utilisation de docker-compose.

J'utilise docker-compose depuis des années et je me suis vite rendu compte de ses limitations.
Si il permet de définir facilement une stack de containers, il n'est pas adapté pour effectuer nombre de tâches lors du lancement de l'application "containerisée".

Par exemple, docker-compose n'est pas adapté pour:
- Lancer l'initialisation des tables de la base de donnée
- Générer des clés
- Ajouter un ou plusieurs utilisateurs d'administration dans l'application "containerisée"
- etc

Si on essaye, on se retrouve à devoir jouer avec les scriptes de points d'entrée (entrypoint) des containers et ça peut vite devenir complexe.
Comme au niveau pro je n'ai pas le choix des outils, je l'utilise malgré tout.

Mais à coté, depuis longtemps, j'utilise aussi Ansible pour l'intégration des applications ("containerisée" ou pas) dans l'infrastructure:
- Déploiement de l'application (ou de sa stack)
- Déploiement des configurations
- Initialisation des tables de la base de donnée
- Génération de clés (et stockage pour plus tard)
- Ajout d'utilisateurs
- Configuration de reverse proxy ou load balancer
- Ajout d'un sous-domaine
- Configuration du système de backup
- Configuration du système de teste de l'infra
- Etc

Les possibilités sont immense.

Mais récemment j'ai décidé de me passer de docker-compose sur mon infrastructure personnelle et d'utiliser directement Ansible pour la définition de la stack de containers.
L'idée c'est d'avoir un rôle Ansible qui déploie l'application et d'utiliser un playbook pour appliquer le rôle, personnaliser l'installation et l'intégrer dans l'infra.

Le rôle s'occupe, par exemple, de:
- Créer les containers
- Déployer les fichiers de configuration avec la config par défaut
- Initialiser la base de données

Les paramètres de l'application ainsi que du déploiement sont personnalisable par des variables dans Ansible.

Le playbook s'occupe de l'intégration dans mon infrastructure:
- Il définit sur quel hôte l'application sera déployée
- Personnalise l'installation
- Créer des utilisateurs
- Configure le reverse proxy
- Configure un sous-domaine pour la nouvelle application

Le rôle est réutilisable et facilement partageable tandis que le playbook est dépendant de l'infrastructure.
Et si je crée un rôle qui déploie son application via des containers Docker, il peut être utilisé sur n'importe quel système où Docker est installé (ou presque).
Et à coté, je crée aussi un playbook qui déploie l'application en locale pour du dev. Mais avec le système de tags d'Ansible ou pourrait avoir un seul playbook qui s'adapte en fonction de la cible (dev/test/prod).

En plus avec l'arrivée des collections Ansible, on a un système qui permet de distribuer en une fois des rôles, des modules, des exemples de playbook et la doc en rapport avec un projet ou une application.

En bref, Ansible m'apporte une plus grand liberté et flexibilité que docker-compose et ce commentaire est beaucoup trop long, j'aurai du créer un journal. :(

Ça a l'aire sympa. Est-ce qu'il y a un package Emacs pour interagir avec depuis Emacs?

Est-ce que Nextcloud pourrait être utilisé comme solution de remplacement? Que manquerait-il?

PS: J'ai entendu dire que la solution de chat audio/vidéo de Nextcloud nécessitait l'usage d'un logiciel privateur. Est-ce que cette information est correct?

Merci beaucoup pour ce journal fort intéressant.

J'ai remarqué une petite erreur dans la section Outils basés sur clang.
Le lien attaché à éditeur favoris est incorrect.
Voici le bon lien: https://github.com/emacs-lsp/lsp-mode

Je dois pouvoir faire un article de présentation. 🤔
Mais il va me falloir un peut de temps, et j'en manque en ce moment. 😣

Hello kinderkinder,

Malheureusement, je ne saurais pas comment t'aider sur ce problème. Je connais peut flash player et son intégration dans les navigateurs.

Mais je t'invite a poser ta question dans la section forums de ce site web: https://linuxfr.org/forums
C'est une section plus adaptée à ce genre de demande. Les journaux était plutôt un espace de publication.

Bonne journée. :)

Emacs rocks

Je suis étonné d'avoir une évaluation aussi basse (-10 à l'écriture de ce commentaire).