Oui, évidemment il y a plus d'accès direct de nos jours. Mais rien n'empêche de faire la même chose pour la mémoire graphique.
Il faudra attendre les spec de Vulkan pour en savoir plus, mais il y a déjà un mec qui parle de pagination pour l'allocation mémoire dans les questions/réponses à la fin de la présentation.
Les mecs sont pas des débutants et ils doivent avoir conscience que si ils veulent avoir la moindre chance que leur truc marche, il faut surtout pas qu'ils pètent les notions élémentaires de séparation des processus.
Si chaque appli a un accès très bas niveau et non contrôlé à ma carte graphique, j'ai peur pour les performances et la stabilité globale de ma machine.
En quoi ça t’inquiète plus que les applis qui ont un accès directe à ton CPU et ta mémoire ?
Les segmentation fault, buffer overflow et autre boucles infinies existent déjà sans le GPU.
On arrive relativement bien à cloisonner (même si c'est pas parfait). Quand mon process plante, mon pc tourne toujours.
On devrait arriver à faire la même chose avec les applis qui utilise le GPU.
Ce journal fait un peu office de journal bookmark, mais je viens de me taper la vidéo d'annonce à la GDC donc voici ma première analyse.
TL;WR
Je viens de finir mon commentaire … et c'est long.
Pour les fainéants : C'est plus bas niveau => Ça à moins de fonctionnalités => C'est plus simple à implémenter => Ça fait des drivers plus performant => C'est cool.
Déjà quelques liens (comme si il n'y en avait pas assez)
À noter que tout cela est très récent. L'annonce à été faite à la GDC (Game Developer Conference) qui n'est toujours pas finie. Les spec de spir-v datent du 2 mars et celles de vulkan ne sont pas encore sorties.
Je parle donc un peu sur le vide. Faudra attendre de voir ce que Khronos va vraiment nous sortir et comment la communauté va adhérer à la techno.
Je décline toute responsabilité si mes prophéties ne se réalise pas :)
Pas de fonctionnalité avancées
Premièrement, Vulkan est très bas niveau. Si vous avez jamais fait d'OpenGL, vous me direz qu'OpenGL l'est aussi. Et je vous répondrai que non. OpenGL arrive avec pas mal de pipeline déjà en place. Le core d'OpenGL3 en a bien moins que les premières versions, mais il en a quand même. Par exemple, le vertex shader, c'est assez libre sur ce qu'il prend en entrée, mais il DOIT prendre au moins un jeu de coordonnées pour chaque vertex, et il DOIT retourné des coord transformées (qui seront obligatoirement traitées par le fragment shader).
Certes OpenGL4 rajoute d'autres types de shaders (geometric shader) mais on reste avec 3/4 types de shader qui traitent les données en séquences. Et comme on veut pas obligatoirement faire des trucs en séquences et qu'on veut quand même utiliser la puissance des gpu, ça donne des trucs assez horrible comme la première page des spec Opengl4.5 (et encore, c'est que le core profile…)
Tout ça pose pas mal de problèmes :
- Les dev veulent plus de contrôles, pour faire des trucs encore plus fou.
- Fournir des fonctionnalités haut-niveau, c'est plus de boulot et c'est du boulot à faire dans les drivers (et de mon avis, ça n'a rien à faire là)
- Ça rajoute aussi de l'overhead. Par exemple la gestion d'erreur : le drivers doit vérifier que les données qu'il manipule sont valide. Hors 99% du temps, on sait qu'elles sont valides (on passe par un moteur 3D qui travaille dans un spectre restreint et validé)
Vulkan prend le parti de revenir à zéro. Il y a aucun état global, aucun pipeline près configurée, pas d'allocation mémoire, pas (moins ?) de gestion d'erreur, …
C'est à l'utilisateur (du driver, donc le dev de l'appli) de définir sa propre pipeline. Quel est le jeu de données en entrée. Quels sont les shaders à appliquer, dans quel ordre et comment les combiner. Quand afficher le buffer.
Ça peut être vu comme plus de travail déporté sur l'appli mais je suis pas sur. Les dev de jeux vidéo passe déjà pas mal de temps à trouver des astuces pour sortir du cadre d'OpenGL. Là ils sont libres, ils font ce qu'ils veulent du hardware.
Après, niveau des shaders, ben on n'en a plus (Ou du moins, c'est plus dans le scope). Vulkan prend du SPIR-V comme code à charger dans le GPU (SPIR-V ayant été développer pour OpenCL à la base). SPIR-V est du bytecode, machine indépendant.
Qui dit plus de shader, dit plus de compilation (dans le drivers). Là aussi moins de boulot pour les drivers.
Et perf ça donne quoi
Vous vous douter bien que c'est mieux. Sinon ça sortirait pas :)
Mais en gros, les implémentations "Work in progress" et les démo montrent un gain assez impressionnant :
- Traduction bourrine opengl=>vulkan : 79% de cycle CPU en moins dans le driver !
- En ayant une architecture multithread vulkan par rapport à monothread opengl (le multithread opengl n'étant pas possible), on à des démo qui tourne plus vite, qui consomme moitié moins niveau GPU et beaucoup moins niveau CPU (je serai pas plus précis, les petits graph ne sont pas très lisible sur la vidéo :) )
Et le libre, bonne ou mauvaise nouvelle ?
Pour moi, c'est clairement une bonne nouvelle.
Les dernières architectures des drivers libres (type Gallium) se basent déjà sur l'idée d'une compilation des shaders en une représentation interne indépendante (en utilisant LLVM). Les drivers spécifiques ayant pour charge de faire tourner cette représentation sur le GPU. Avec Vulkan, c'est une grosse partie des drivers à ne plus implémenter. On prend juste du SPIR-V et on l'envoie sur le GPU. Et il y a fort à parier que dans le futur, le GPU sache directement exécuter du SPIR-V, donc.. quasiment rien à faire (Enfin, bon, il y aura quand même du boulot hein :) )
Moins de travail à faire aussi sur l'allocation de mémoire. C'est à l'appli de le gérer et elle va utiliser les mécanismes déjà en place dans le kernel pour ça.
Le fait qu'il y ai moins de travail à faire, remet aussi les drivers libre dans la course niveau performance. À ma connaissance (et là je suis pas le mieux placé), le gros bottleneck niveau perf dans le drivers, c'est justement la compilation des shaders et la gestion de la mémoire. Là, c'est reporté sur l'appli donc toutes les plateformes se retrouvent "au même niveau".
Niveau API, c'est plus bas niveau, donc c'est plus compliqué. C'est mieux pour les gros dev de jeux vidéo. Pour les "petits dev", je pense que c'est pas trop un pb puisque opengl va continuer d'exister. Il pourrait même "juste" devenir une "simple" bibliothèque basée sur Vulkan et qui s'occupe de compiler du shader et configurer des pipelines.
Jouer avec Requires, Provides, je me disais que peut etre il irait chercher les dépendances nécessaire il semblerait pas je n'ai que des fichiers de messages informatifs.
C'est, à priori, la bonne solution. Par contre rpm n'installe pas les dépendances tout seul.
Il vérifie les 'Requires' et échoue si ils ne sont pas présent. Mais il ne va pas chercher les rpm qui fournissent les dép.
C'est pour ma qu'on a des outils de types yum/dnf/urpmi/etc…
Avec yum, si tu as un paquet qui a tout les bons 'Requires' et tout les rpm dans le même dossier, tu peux faire :
cd <dossier_rpms>
yum localinstall paquet_avec_requires.rpm
Pour une solution plus générale, il faudra créer un repo pour que yum soit capable de résoudre les dépendances.
C'est gratuit … mais pas trop. Il faudra payer 5% de taxes sur revenus à partir de 3000 ventes/produit/trimestre.
C'est open source.
À cause du premier point, c'est surement pas libre.
Le code source est probablement disponible ici, mais vu qu'il faut s'inscrire et que je l'ai pas fait, je garanti rien.
Pour ce qui est modifiable, c'est de pratique assez courante (il me semble) dans le jeux-vidéo d'avoir le code source (et le droit de le modifier) quand on achète un moteur. Je pense que d'aura le droit de modifier le code donc.
À noter que le code source était déjà disponible. Il fallait payer 19€/mois pour profiter d'unreal engine 4. Il semble donc que ce soit juste le mode de facturation qui change.
Lorsque tu parcours ta list et crées tes lambdas, tu crées n fonctions (6 dans ton cas) qui sont toutes liées au même namespace (dans lequel elles ont été créées).
Quand Tkinter appelle ces callbacks, elles vont toutes aller chercher la valeur de key dans le namespace les contenant. Comme elles partagent le même namespace, elle trouve la même valeur. Et la valeur de key, c'est "but6", la dernière valeur attribuer à key.
La solution est de forcer la "résolution" de key au moment où la lambda est créée et pas quand elle est exécutée.
Pour ce faire, l'idiome courant en python est d'utiliser un argument ayant une valeur par défaut:
# code simplifié pour l'exemple :list=["but1","but2","but3","but4","but5","but6"]forkeyinlist:ui.key=Button(ui,text=key,command=lambdak=key:print(k))ui.key.pack(side=LEFT,padx=2,pady=2)
Ainsi, lorsque la lambda est exécutée, elle utilise la valeur de k (son argument) qui à pour valeur la valeur de key (variable global) au moment de sa définition.
Il existe aussi une autre façon de faire, créer un namespace par fonction, dans lequel la closure ira chercher:
defcreate_callback(key):"""Cet fonction va créer une callback et la retourner à l'appelant Comme chaque appel de fonction crée un nouveau namespace et que la callback est créée dans ce namespace, chaque callback a son namespace. """def_callback():print(key)return_callbacklist=["but1","but2","but3","but4","but5","but6"]forkeyinlist:ui.key=Button(ui,text=key,command=create_callback(key))ui.key.pack(side=LEFT,padx=2,pady=2)
J'ai l'impression en fait que tu cherches une approche par patches.
Chaque "features" branches est en fait un patch disponible pour intégration/test.
Certes il existe plusieurs petit commits pour une seul branche mais le diff (head - master) représente un seul et unique patch que vous voulez appliquer ou pas.
Dans ce context, j'aurai plutôt une approche de ce type :
Une branche master qui ne contient que les fonctionnalité validé (et donc finale).
Une branche par fonctionnalité. Au maximum basé sur la tête le master HEAD. Éventuellement, si une fonctionnalité B dépend d'une fonctionnalité A, alors branche_B est basée sur branche_A au lieu de master.
Un magnifique script que je vous laisse développer qui merge le tout (les fonctionnalité que tu veux tester) dans une branche d'intégration "temporaire"
si tes tests fonctionnels sont bon, master fast-forward sur la branche d'intégration. Les branches de fonctionnalités non mergées sont rebasé sur le nouveau HEAD
si tes tests fonctionnels passent pas, tu vires la branches (ou tu la laisse de coté pour l'historique) et tu créés une nouvelle branche d'intégration pour les tests suivants.
C'est globalement la même chose que ce que tu as, mais sans branche d'intégration "réelle". Les branches d'intégrations sont temporaires et privées (pour les tests).
Le fait que tes merges de features soient automatisés doit améliorer le git-rerere. En effet, si tu changes juste un truc dans une branche, tu repars toujours du même point et tu applique tout tes patchs/merge dans le même ordre. Donc tu te retrouves à corriger que les conflits ajoutés par le changement que tu viens de faire.
Tu simplifies aussi le boulot d'intégrateur puisque qu'il se retrouve à "seulement" décider quels patches tester, lancer le script et corriger les nouveaux conflit.
Au niveau outils, il y a stgit qui gèrent une séries de patch par dessus une tête de branche. Chaque patch est versionné dans une branche git séparée. Je sais pas si ça correspond à ton besoin car stgit construit lui-même les branches en fonctions des fichiers .patch que tu lui donne à manger, mais ça peut donner des idées.
Pourquoi un occidental doit-il travailler 8h par jours pour vivre alors qu'un indigène qui > vit dans la cambrousse n'a besoin que d'une a deux heures pour faire toutes les choses qui > lui sont vitale (nourrir sa famille, entretenir son territoire)
Parce qu'un occidental veut plus que le minimum vital (probablement comme l'indigène qui se la coulerait douce dans la cambrousse*) ?
Parce qu'un occidental a plus que le minimum vital (contrairement à l'indigène dans sa cambrousse) ?
*Enfin c'est pas moi qui le dit. Ça m'étonnerai qu'un indigène bosse deux heures/jour et qu'il regarde des vidéo sur youpo^W youtube le reste de la journée…
D'une part, tu ne travaille pas pour un musée. C'est un musée qui t'ouvre ces portes. C'est toi (en équipe certes) qui choisis l'oeuvre que tu veux museomixer. Le musée n'a pas de demande particulière et il ne peut imposer son choix.
Deuxièmement, ton travail reste ta propriété. Pas celle de museomix, pas celle du musée. C'est un prototype que tu crées. Il est desinstallé à la fin du we. Si le musée est intéressé par ton prototype, c'est à lui de trouver un budget pour le pérenniser. Et là, tu te fais payer (si tu es le prestataire qui fait le boulot). Et museomix n'est plus dans l'équation à ce moment là. Et c'est déjà arrivé dans des éditions précédentes.
Enfin, 50 € pour la bouffe de tout un we c'est pas énorme. Surtout si on rajoute l'accès au musée, le personnel du musée qui est mobilisé le we, le matos du fablab,… Tout ça pour un proto qui est démonté à la fin du we. Je pense que d'autre que toi mettent bien plus d'argent sans en retirer beaucoup de bénef.
Alors oui, tu payes 50€, mais comme exploitation de ton savoir faire, j'ai vu franchement pire.
oui, les scripts Debian sont compatibles avec des distributions utilisant des scripts Debian, les scripts RedHat sont compatibles avec des distributions utilisant des scripts RedHat, et les scripts/unités systemd sont compatibles avec les distributions utilisant des scripts/unités systemd. Super.
Non :
Les scripts SysVinit Debian sont compatibles avec les distributions SysVinit Debian et systemd Debian. Les scripts SysVinit RedHat sont compatibles avec les distributions SysVinit RedHat et systemd RedHat. Et les unités systemd sont compatibles avec les distributions systemd Debian et systemd RedHat.
Pour ma part, niveau lisibilité, je préfère encore le xml.
Par contre, comme tu l'explique sur ton blog, le fait que ce soit orienté ligne rend le format pas mal pour l'interop avec les outils classiques (sed, grep, …).
Mais je risque pas de l'utiliser pour mes fichiers de conf.
<comtype="commentaire"><questionto="jbbourgoin">
Comment tu traduis ma question en LISP ?
<complementtype="réécriture de la question">
Comment ça se passe avec les attributs ?
</complement></question></com>
Non, tout n'est pas dans le titre :) Je ne demande pas que ce journal soit promut en dépêche.
Ton projet a l'air intéressant, mais ne connaissant pas vraiment le domaine, j'ai un peu de mal à juger et le situer par rapport au reste (ainsi qu'a mes potentiels besoins)
Vous êtes plusieurs à avoir de s'y connaitre dans le domaine. Si vous n'avez rien à faire, je serais bien intéressé par un dépêche que vous pourriez faire à ce sujet.
Genre:
Qu'est ce qu'un spec (bon, ça je sais, mais ça fait pas de mal de le rappeler)
À quoi ça ressemble (idem)
Comment vérifier qu'une spec est complète (si possible?)
Comment vérifier qu'un code correspond à la spec
Comment générer des tests qui vérifient la spec
Quels sont les outils utilisés
Les différents cas d'utilisation
Des exemples
La différence entre Reqflow et Doors
Plein de trucs auxquels je ne pense pas parce que je connais pas…
J'ai pas envie de partir dans un enième debat, python vs <insert your language>
Je te répondait juste sur le fait tu peux ne pas demander à un IDE de savoir quand le dev veut terminer son bloc (python ou autre). Et l'indentation fait partir de la sémantique de python, tu ne peux pas demander à un IDE de refaire ton indentation.
(Après, je te dirait bien qu'il faut revoir ton outil de merge si il te fait sauter les espaces de début de ligne de ce qu'il merge)
En fait, il est même pas nécessaire que l'appli affiche le certificat visuel.
Le compositeur peut le faire de lui-même. L'important est que l'utilisateur le choisisse pour qu'il ne puisse pas être connu par une appli malveillante.
Bon, j'ai un peu de retard, mais quand même (merci au résumé des meilleurs articles qui ma permit de ne pas louper les derniers commentaires)
Ça demande un peu de réflexion et probablement de l'ajustement mais l'idée est d'avoir un identifiant visuel qui permettrait aux applications autorisées de s’authentifier auprès des utilisateurs.
À la création d'un compte, l'utilisateur choisi un "certificat visuel" (plus ou moins en même temps qu'il renseigne son mdp). Ce certificat visuel (CV) serait par exemple une image de 100x100 en RGB, ça peut être une photo, un schéma dessiné à la souris ou un mot stocké sous forme d'image. Le CV est stocké de manière sécurisé et accessible par le compositeur seulement. Lorsqu'une application autorisé veut demander un mdp à l'utilisateur, elle doit demander ce CV et l'afficher à l'utilisateur. L'utilisateur à la garantie que c'est bien une appli autorisée car il voit le CV qu'il a choisi.
Une appli mal intentionnée ne peut pas accéder au CV et ne peut donc pas s'authentifier auprès de l'utilisateur. Ça reste à l'utilisateur de vérifier qu'il voit son CV avant de rentré le mdp, mais ça reste une vérification pas trop contraignante, facile et rapide à effectuer.
[^] # Re: Des oh et des bah
Posté par GaMa (site web personnel) . En réponse au journal Vulkan le successeur d'OpenGL. Évalué à 2.
Oui, évidemment il y a plus d'accès direct de nos jours. Mais rien n'empêche de faire la même chose pour la mémoire graphique.
Il faudra attendre les spec de Vulkan pour en savoir plus, mais il y a déjà un mec qui parle de pagination pour l'allocation mémoire dans les questions/réponses à la fin de la présentation.
Les mecs sont pas des débutants et ils doivent avoir conscience que si ils veulent avoir la moindre chance que leur truc marche, il faut surtout pas qu'ils pètent les notions élémentaires de séparation des processus.
Matthieu Gautier|irc:starmad
[^] # Re: Des oh et des bah
Posté par GaMa (site web personnel) . En réponse au journal Vulkan le successeur d'OpenGL. Évalué à 0.
En quoi ça t’inquiète plus que les applis qui ont un accès directe à ton CPU et ta mémoire ?
Les segmentation fault, buffer overflow et autre boucles infinies existent déjà sans le GPU.
On arrive relativement bien à cloisonner (même si c'est pas parfait). Quand mon process plante, mon pc tourne toujours.
On devrait arriver à faire la même chose avec les applis qui utilise le GPU.
Matthieu Gautier|irc:starmad
# Mon analyse.
Posté par GaMa (site web personnel) . En réponse au journal Vulkan le successeur d'OpenGL. Évalué à 10.
Sommaire
Ce journal fait un peu office de journal bookmark, mais je viens de me taper la vidéo d'annonce à la GDC donc voici ma première analyse.
TL;WR
Je viens de finir mon commentaire … et c'est long.
Pour les fainéants : C'est plus bas niveau => Ça à moins de fonctionnalités => C'est plus simple à implémenter => Ça fait des drivers plus performant => C'est cool.
Déjà quelques liens (comme si il n'y en avait pas assez)
À noter que tout cela est très récent. L'annonce à été faite à la GDC (Game Developer Conference) qui n'est toujours pas finie. Les spec de spir-v datent du 2 mars et celles de vulkan ne sont pas encore sorties.
Je parle donc un peu sur le vide. Faudra attendre de voir ce que Khronos va vraiment nous sortir et comment la communauté va adhérer à la techno.
Je décline toute responsabilité si mes prophéties ne se réalise pas :)
Pas de fonctionnalité avancées
Premièrement, Vulkan est très bas niveau. Si vous avez jamais fait d'OpenGL, vous me direz qu'OpenGL l'est aussi. Et je vous répondrai que non. OpenGL arrive avec pas mal de pipeline déjà en place. Le core d'OpenGL3 en a bien moins que les premières versions, mais il en a quand même. Par exemple, le vertex shader, c'est assez libre sur ce qu'il prend en entrée, mais il DOIT prendre au moins un jeu de coordonnées pour chaque vertex, et il DOIT retourné des coord transformées (qui seront obligatoirement traitées par le fragment shader).
Certes OpenGL4 rajoute d'autres types de shaders (geometric shader) mais on reste avec 3/4 types de shader qui traitent les données en séquences. Et comme on veut pas obligatoirement faire des trucs en séquences et qu'on veut quand même utiliser la puissance des gpu, ça donne des trucs assez horrible comme la première page des spec Opengl4.5 (et encore, c'est que le core profile…)
Tout ça pose pas mal de problèmes :
- Les dev veulent plus de contrôles, pour faire des trucs encore plus fou.
- Fournir des fonctionnalités haut-niveau, c'est plus de boulot et c'est du boulot à faire dans les drivers (et de mon avis, ça n'a rien à faire là)
- Ça rajoute aussi de l'overhead. Par exemple la gestion d'erreur : le drivers doit vérifier que les données qu'il manipule sont valide. Hors 99% du temps, on sait qu'elles sont valides (on passe par un moteur 3D qui travaille dans un spectre restreint et validé)
Vulkan prend le parti de revenir à zéro. Il y a aucun état global, aucun pipeline près configurée, pas d'allocation mémoire, pas (moins ?) de gestion d'erreur, …
C'est à l'utilisateur (du driver, donc le dev de l'appli) de définir sa propre pipeline. Quel est le jeu de données en entrée. Quels sont les shaders à appliquer, dans quel ordre et comment les combiner. Quand afficher le buffer.
Ça peut être vu comme plus de travail déporté sur l'appli mais je suis pas sur. Les dev de jeux vidéo passe déjà pas mal de temps à trouver des astuces pour sortir du cadre d'OpenGL. Là ils sont libres, ils font ce qu'ils veulent du hardware.
Après, niveau des shaders, ben on n'en a plus (Ou du moins, c'est plus dans le scope). Vulkan prend du SPIR-V comme code à charger dans le GPU (SPIR-V ayant été développer pour OpenCL à la base). SPIR-V est du bytecode, machine indépendant.
Qui dit plus de shader, dit plus de compilation (dans le drivers). Là aussi moins de boulot pour les drivers.
Et perf ça donne quoi
Vous vous douter bien que c'est mieux. Sinon ça sortirait pas :)
Mais en gros, les implémentations "Work in progress" et les démo montrent un gain assez impressionnant :
- Traduction bourrine opengl=>vulkan : 79% de cycle CPU en moins dans le driver !
- En ayant une architecture multithread vulkan par rapport à monothread opengl (le multithread opengl n'étant pas possible), on à des démo qui tourne plus vite, qui consomme moitié moins niveau GPU et beaucoup moins niveau CPU (je serai pas plus précis, les petits graph ne sont pas très lisible sur la vidéo :) )
Et le libre, bonne ou mauvaise nouvelle ?
Pour moi, c'est clairement une bonne nouvelle.
Les dernières architectures des drivers libres (type Gallium) se basent déjà sur l'idée d'une compilation des shaders en une représentation interne indépendante (en utilisant LLVM). Les drivers spécifiques ayant pour charge de faire tourner cette représentation sur le GPU. Avec Vulkan, c'est une grosse partie des drivers à ne plus implémenter. On prend juste du SPIR-V et on l'envoie sur le GPU. Et il y a fort à parier que dans le futur, le GPU sache directement exécuter du SPIR-V, donc.. quasiment rien à faire (Enfin, bon, il y aura quand même du boulot hein :) )
Moins de travail à faire aussi sur l'allocation de mémoire. C'est à l'appli de le gérer et elle va utiliser les mécanismes déjà en place dans le kernel pour ça.
Le fait qu'il y ai moins de travail à faire, remet aussi les drivers libre dans la course niveau performance. À ma connaissance (et là je suis pas le mieux placé), le gros bottleneck niveau perf dans le drivers, c'est justement la compilation des shaders et la gestion de la mémoire. Là, c'est reporté sur l'appli donc toutes les plateformes se retrouvent "au même niveau".
Niveau API, c'est plus bas niveau, donc c'est plus compliqué. C'est mieux pour les gros dev de jeux vidéo. Pour les "petits dev", je pense que c'est pas trop un pb puisque opengl va continuer d'exister. Il pourrait même "juste" devenir une "simple" bibliothèque basée sur Vulkan et qui s'occupe de compiler du shader et configurer des pipelines.
My 2 cents.
Matthieu Gautier|irc:starmad
# Dépendances entre rpm
Posté par GaMa (site web personnel) . En réponse au message RPM dans un RPM. Évalué à 6.
C'est, à priori, la bonne solution. Par contre rpm n'installe pas les dépendances tout seul.
Il vérifie les 'Requires' et échoue si ils ne sont pas présent. Mais il ne va pas chercher les rpm qui fournissent les dép.
C'est pour ma qu'on a des outils de types yum/dnf/urpmi/etc…
Avec yum, si tu as un paquet qui a tout les bons 'Requires' et tout les rpm dans le même dossier, tu peux faire :
Pour une solution plus générale, il faudra créer un repo pour que yum soit capable de résoudre les dépendances.
Matthieu Gautier|irc:starmad
# L'origine
Posté par GaMa (site web personnel) . En réponse au message Unreal engine gratuit oui ! Libre non ! Mais open source ? . Évalué à 1.
Voici le lien vers l'article de blog unrealengine qui annonce la nouvelle: https://www.unrealengine.com/blog/ue4-is-free
Ensuite (parce que lit l'anglais :) ):
Le code source est probablement disponible ici, mais vu qu'il faut s'inscrire et que je l'ai pas fait, je garanti rien.
Pour ce qui est modifiable, c'est de pratique assez courante (il me semble) dans le jeux-vidéo d'avoir le code source (et le droit de le modifier) quand on achète un moteur. Je pense que d'aura le droit de modifier le code donc.
À noter que le code source était déjà disponible. Il fallait payer 19€/mois pour profiter d'unreal engine 4. Il semble donc que ce soit juste le mode de facturation qui change.
Matthieu Gautier|irc:starmad
# Beaucoup plus simple
Posté par GaMa (site web personnel) . En réponse au journal Retour d'expérience : bureau assis/debout. Évalué à 10.
Merci pour ce retour complet.
Je suis tout a fait d'accord avec toi sur le problème (Besoin de se lever de temps en temps. Position debout dure à tenir)
Pour la solution part contre, j'ai trouvé bien plus simple : Une table haute et une chaise haute (genre chaise de bar).
Quand je veux être debout, je vire la chaise. Quand je veux m'assoir… je m'assoie :)
Matthieu Gautier|irc:starmad
# Namespace et closure.
Posté par GaMa (site web personnel) . En réponse au message Problème de callback avec Tkinter. Évalué à 6.
C'est un problème de python et pas de tkinter.
Lorsque tu parcours ta list et crées tes lambdas, tu crées n fonctions (6 dans ton cas) qui sont toutes liées au même namespace (dans lequel elles ont été créées).
Quand Tkinter appelle ces callbacks, elles vont toutes aller chercher la valeur de key dans le namespace les contenant. Comme elles partagent le même namespace, elle trouve la même valeur. Et la valeur de key, c'est "but6", la dernière valeur attribuer à key.
La solution est de forcer la "résolution" de key au moment où la lambda est créée et pas quand elle est exécutée.
Pour ce faire, l'idiome courant en python est d'utiliser un argument ayant une valeur par défaut:
Ainsi, lorsque la lambda est exécutée, elle utilise la valeur de k (son argument) qui à pour valeur la valeur de key (variable global) au moment de sa définition.
Il existe aussi une autre façon de faire, créer un namespace par fonction, dans lequel la closure ira chercher:
Matthieu Gautier|irc:starmad
# Avec le lien, c'est mieux
Posté par GaMa (site web personnel) . En réponse au journal Ebooks technique gratuits. Évalué à 6.
J'ai bien sur oublier le lien le plus important :
https://www.packtpub.com/packt/offers/free-learning
Matthieu Gautier|irc:starmad
[^] # Re: Pareil
Posté par GaMa (site web personnel) . En réponse au journal Mozilla est-il en train de devenir un Google junior?. Évalué à 4.
Et ils ne pourraient pas simplement dire : "Nous ne fournissons pas de support technique si vous utilisez des extensions non signées" ?
Matthieu Gautier|irc:starmad
# Patch
Posté par GaMa (site web personnel) . En réponse au journal Git workflow, rebase, conflits et rôle d'intégrateur. Évalué à 3.
J'ai pas de solution toute faite mais une piste.
J'ai l'impression en fait que tu cherches une approche par patches.
Chaque "features" branches est en fait un patch disponible pour intégration/test.
Certes il existe plusieurs petit commits pour une seul branche mais le diff (head - master) représente un seul et unique patch que vous voulez appliquer ou pas.
Dans ce context, j'aurai plutôt une approche de ce type :
C'est globalement la même chose que ce que tu as, mais sans branche d'intégration "réelle". Les branches d'intégrations sont temporaires et privées (pour les tests).
Le fait que tes merges de features soient automatisés doit améliorer le git-rerere. En effet, si tu changes juste un truc dans une branche, tu repars toujours du même point et tu applique tout tes patchs/merge dans le même ordre. Donc tu te retrouves à corriger que les conflits ajoutés par le changement que tu viens de faire.
Tu simplifies aussi le boulot d'intégrateur puisque qu'il se retrouve à "seulement" décider quels patches tester, lancer le script et corriger les nouveaux conflit.
Au niveau outils, il y a stgit qui gèrent une séries de patch par dessus une tête de branche. Chaque patch est versionné dans une branche git séparée. Je sais pas si ça correspond à ton besoin car stgit construit lui-même les branches en fonctions des fichiers .patch que tu lui donne à manger, mais ça peut donner des idées.
Matthieu Gautier|irc:starmad
[^] # Re: Oui, et ?
Posté par GaMa (site web personnel) . En réponse au journal "Comment les multinationales (y compris françaises) font de l’évasion fiscale au Luxembourg". Évalué à 4.
Parce qu'un occidental veut plus que le minimum vital (probablement comme l'indigène qui se la coulerait douce dans la cambrousse*) ?
Parce qu'un occidental a plus que le minimum vital (contrairement à l'indigène dans sa cambrousse) ?
*Enfin c'est pas moi qui le dit. Ça m'étonnerai qu'un indigène bosse deux heures/jour et qu'il regarde des vidéo sur youpo^W youtube le reste de la journée…
Matthieu Gautier|irc:starmad
[^] # Re: VirtualBox
Posté par GaMa (site web personnel) . En réponse au message Formatage de documents Word sous Linux. Évalué à 4.
Ouai, vaut mieux directement acheter un deuxième pc dédier à MSOffice quand on arrive à ce niveau…
Matthieu Gautier|irc:starmad
[^] # Re: Une anecdote en passant
Posté par GaMa (site web personnel) . En réponse au journal Marque page sur l'unification possible des systèmes Linux. Évalué à 9.
<HS>
C'est possible de savoir où c'était ?
J'ai été presta au CEA et j'ai codé un outil python qui faisait globalement ce que tu décris (et un peu plus).
Soit on parle du même outil, soit chacun refait ses trucs dans son coin.
<\HS>
Matthieu Gautier|irc:starmad
[^] # Re: 50€
Posté par GaMa (site web personnel) . En réponse à la dépêche Museomix cherche des développeurs. Évalué à 5.
Oui, enfin c'est une question de point de vue…
D'une part, tu ne travaille pas pour un musée. C'est un musée qui t'ouvre ces portes. C'est toi (en équipe certes) qui choisis l'oeuvre que tu veux museomixer. Le musée n'a pas de demande particulière et il ne peut imposer son choix.
Deuxièmement, ton travail reste ta propriété. Pas celle de museomix, pas celle du musée. C'est un prototype que tu crées. Il est desinstallé à la fin du we. Si le musée est intéressé par ton prototype, c'est à lui de trouver un budget pour le pérenniser. Et là, tu te fais payer (si tu es le prestataire qui fait le boulot). Et museomix n'est plus dans l'équation à ce moment là. Et c'est déjà arrivé dans des éditions précédentes.
Enfin, 50 € pour la bouffe de tout un we c'est pas énorme. Surtout si on rajoute l'accès au musée, le personnel du musée qui est mobilisé le we, le matos du fablab,… Tout ça pour un proto qui est démonté à la fin du we. Je pense que d'autre que toi mettent bien plus d'argent sans en retirer beaucoup de bénef.
Alors oui, tu payes 50€, mais comme exploitation de ton savoir faire, j'ai vu franchement pire.
Matthieu Gautier|irc:starmad
[^] # Re: prendre un projet deja fait et le modifier
Posté par GaMa (site web personnel) . En réponse au message Cross-compiler pour OS X?. Évalué à 2.
Et puis c'est surtout que OSx utilise le format Mach-O et que linux utilise ELF.
Donc même si c'est livré en compilé dynamique, il y a peu de chance que ça fonctionne.
Matthieu Gautier|irc:starmad
[^] # Re: De plus en plus complexe, le système d'init...
Posté par GaMa (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 5.
Comment tu gères ces dépendances avec des scripts bash ?
Ça c'est vrai tout le temps, pourquoi ça pose un problème avec systemd ?
Matthieu Gautier|irc:starmad
[^] # Re: De plus en plus complexe, le système d'init...
Posté par GaMa (site web personnel) . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 7.
Non :
Les scripts SysVinit Debian sont compatibles avec les distributions SysVinit Debian et systemd Debian. Les scripts SysVinit RedHat sont compatibles avec les distributions SysVinit RedHat et systemd RedHat. Et les unités systemd sont compatibles avec les distributions systemd Debian et systemd RedHat.
(Tu vois pas comme une petite différence ?)
Matthieu Gautier|irc:starmad
[^] # Re: Juste une question : quel est l'intérêt d'un CGI aujourd'hui ?
Posté par GaMa (site web personnel) . En réponse au message débugguer un CGI avec GDB ( sous apache2 ). Évalué à 1.
C'est quoi le web ? (non interactif).
Tu poses un question et il te répond pas ?
Matthieu Gautier|irc:starmad
[^] # Re: XML
Posté par GaMa (site web personnel) . En réponse au journal XML c'est de la daube!!!. Évalué à 4.
Pour ma part, niveau lisibilité, je préfère encore le xml.
Par contre, comme tu l'explique sur ton blog, le fait que ce soit orienté ligne rend le format pas mal pour l'interop avec les outils classiques (sed, grep, …).
Mais je risque pas de l'utiliser pour mes fichiers de conf.
Matthieu Gautier|irc:starmad
[^] # Re: XML
Posté par GaMa (site web personnel) . En réponse au journal XML c'est de la daube!!!. Évalué à 5.
Matthieu Gautier|irc:starmad
# Dépêche ?
Posté par GaMa (site web personnel) . En réponse au journal Reqflow. Évalué à 10.
Non, tout n'est pas dans le titre :) Je ne demande pas que ce journal soit promut en dépêche.
Ton projet a l'air intéressant, mais ne connaissant pas vraiment le domaine, j'ai un peu de mal à juger et le situer par rapport au reste (ainsi qu'a mes potentiels besoins)
Vous êtes plusieurs à avoir de s'y connaitre dans le domaine. Si vous n'avez rien à faire, je serais bien intéressé par un dépêche que vous pourriez faire à ce sujet.
Genre:
Merci d'avance :)
Matthieu Gautier|irc:starmad
[^] # Re: goto
Posté par GaMa (site web personnel) . En réponse au journal <3 goto. Évalué à 1.
J'ai pas envie de partir dans un enième debat, python vs <insert your language>
Je te répondait juste sur le fait tu peux ne pas demander à un IDE de savoir quand le dev veut terminer son bloc (python ou autre). Et l'indentation fait partir de la sémantique de python, tu ne peux pas demander à un IDE de refaire ton indentation.
(Après, je te dirait bien qu'il faut revoir ton outil de merge si il te fait sauter les espaces de début de ligne de ce qu'il merge)
Matthieu Gautier|irc:starmad
[^] # Re: goto
Posté par GaMa (site web personnel) . En réponse au journal <3 goto. Évalué à 2.
Je ne peux être que d'accord avec toi. Mais est-ce que tu connais des IDE capable de remettre les '}' au bon endroit ?
Matthieu Gautier|irc:starmad
[^] # Re: Boite de dialogue pour les mots de passe
Posté par GaMa (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 2.
En fait, il est même pas nécessaire que l'appli affiche le certificat visuel.
Le compositeur peut le faire de lui-même. L'important est que l'utilisateur le choisisse pour qu'il ne puisse pas être connu par une appli malveillante.
Matthieu Gautier|irc:starmad
[^] # Re: Boite de dialogue pour les mots de passe
Posté par GaMa (site web personnel) . En réponse au journal Compositeurs Wayland - Pourquoi et comment gérer les clients privilégiés?. Évalué à 7.
Bon, j'ai un peu de retard, mais quand même (merci au résumé des meilleurs articles qui ma permit de ne pas louper les derniers commentaires)
Ça demande un peu de réflexion et probablement de l'ajustement mais l'idée est d'avoir un identifiant visuel qui permettrait aux applications autorisées de s’authentifier auprès des utilisateurs.
À la création d'un compte, l'utilisateur choisi un "certificat visuel" (plus ou moins en même temps qu'il renseigne son mdp). Ce certificat visuel (CV) serait par exemple une image de 100x100 en RGB, ça peut être une photo, un schéma dessiné à la souris ou un mot stocké sous forme d'image. Le CV est stocké de manière sécurisé et accessible par le compositeur seulement. Lorsqu'une application autorisé veut demander un mdp à l'utilisateur, elle doit demander ce CV et l'afficher à l'utilisateur. L'utilisateur à la garantie que c'est bien une appli autorisée car il voit le CV qu'il a choisi.
Une appli mal intentionnée ne peut pas accéder au CV et ne peut donc pas s'authentifier auprès de l'utilisateur. Ça reste à l'utilisateur de vérifier qu'il voit son CV avant de rentré le mdp, mais ça reste une vérification pas trop contraignante, facile et rapide à effectuer.
Matthieu Gautier|irc:starmad