GuieA_7 a écrit 675 commentaires

Qu'entendez vous par simple ? simple à installer ? simple à configurer ? simple à modifier ? simple à utiliser (une fois installé/configuré) ?

Je suis le développeur principal de CremeCRM:

• ça gère la relation clients, les devis & factures.
• c'est en Python.
• ce n'est pas trop dur à installer (pour une personne qui sait lancer 3 commandes dans un terminal).
• par défaut ça gère beaucoup plus de choses que ce que vous demandez, mais en passant 15 minutes dans l'interface de configuration vous pouvez enlever la plupart des choses dont vous n'avez pas besoin (que ce soit des blocs, boutons, champs…).
• assez simple à hacker pour les besoins les plus pointus.

Peut-être que cela vous donnera une piste.

Merci pour ces explications !

D'une part, il y a le problème du temps de compilation qui affecte Rust parce que le compilateur Rust émet des formes intermédiaires LLVM de mauvaise qualité, que LLVM met beaucoup de temps à compiler.

rustc a introduit il y a quelques années une représentation intermédiaire (appelée MIR—voir cet article par exemple) qui permet de faire "facilement" des optimisations avec la sémantique de Rust que LLVM ne pouvait pas faire (ou difficilement) et qui a permis de gagner en temps de compilation (entre autres choses), même si ça sera toujours perfectible. LLVM est quand même pas mal tourné vers C/C++ (pour des raisons évidentes), mais au final il y a tellement de gens qui travaillent dessus que faire une solution ad-hoc qui fasse mieux est loin d'être évident. Il y a aussi un travail en cours pour un frontend Rust à GCC ; je ne sais pas si/quand ça aboutira, mais je ne serais pas étonné qu'il y ait le même genre d'écueils.

Oui tout à fait, ça revient un peu à faire jouer une IA sur un jeu d'échec en ligne par exemple. Et même si tu fais jouer les gens en présentiel, un jour tu pourras te faire assister par une puce cérébrale, qu'on se mettra à essayer de détecter, etc… Bref c'est l'éternelle lutte de l'épée contre le bouclier.

Le compilateur OCaml gère deux modes de compilation : un mode bytecode qui fonctionne sur toute architecture où un compilateur C est disponible ; et un mode natif qui émet directement des binaires natifs.

Hum je ne suis pas sûr d'avoir bien compris cette phrase. Tel que je l'avais compris ces dernières années, le compilateur pouvait :

• soit générer un bytecode destiné à une VM spécifique (le code est portable, il "suffit" que la VM ait été portée sur la plateforme, comme d'habitude)
• soit générer du C, qui est alors passé à un compilateur C afin de générer un exécutable natif, l'idée étant d'avoir un compilateur ciblant beaucoup de plateformes avec relativement peu d'effort (l'équipe derrière OCaml étant plutôt petite). J'imagine que faire un frontend GCC demande plus d'efforts que pondre du C (et LLVM est plus récent—j'ai entendu parlé d'un projet de frontend OCaml pour ce dernier mais je ne sais pas où ça en est).

Le bout de phrase "un mode bytecode qui fonctionne sur toute architecture où un compilateur C est disponible" c'est parce que la VM est écrite en C très portable ? C'est une erreur ? N'ai-je rien compris ?

Glaneur de Cellule (GC)

C'est la première fois que je vois cette traduction, j'aime beaucoup.

C'est quoi l'intérêt pour le joueur, de tricher?

Une fois qu'on a vaincu tous les monstres, qu'on a tout vu, l'intérêt d'un jeu se perd.

Il est clair que dans un jeu purement solo, on se fiche (ou en tout cas on devrait) qu'un joueur triche. Si une personne prend du plaisir en allant voir directement l'identité du tueur quand elle lit un polar, en sautant 90% du livre, c'est son droit ; les créateurs (que ce soit un livre, film, jeu vidéo…) proposent une expérience telle qu'ils la pensent intéressante, les utilisateurs/consommateurs en font ce qu'ils veulent. Donc protéger cette expérience via du logiciel propriétaire (voire des logiciels anti-triche) est clairement une aberration.

Mais pour des jeux multi-joueurs en ligne la question se pose. Il y a toujours eu, bien avant le jeu vidéo, des gens qui préfèrent tricher plutôt que perdre (ou n'être que 2ème) ; c'est triste je te l'accorde, mais c'est comme ça. Et ces tricheurs rendent l'expérience moins bonne pour les joueurs honnêtes.

En l'occurrence ces systèmes anti-triche sont plutôt associés à des jeux multi-joueur en ligne (en tout cas il me semble, je ne pratique pas les jeux proprios sur PC).

À la fin, les joueurs joueront sans le tricheur…

Tu pars du principe que c'est facile de savoir qu'une personne triche; ce n'est pas forcément le cas.

• la triche peut permettre de gonfler artificiellement son niveau sans faire des choses fondamentalement illégitimes (comme avoir des munitions illimitées dans un jeu où elles ne doivent pas l'être) (voir exemple les wall hacks qui permettent de voir à travers les murs).
• dans des jeux avec énormément de joueurs, où tu es amené à croiser des gens que tu ne croiseras parfois plus jamais, comment savoir qu'une personne triche bien ou est juste forte ?

Chose qui à été résolu depuis peu en ajoutant le calcul de distance entre le coffre et le joueur pour permettre l’interaction.

C'est très naïf de croire que les devs de Minetest ont globalement résolu le problème de la triche dans les jeux, que la solution consistait à mettre un test côté serveur, et que personne dans l'industrie du JV n'y a pensé.

Faire tourner toute la simulation côté serveur [*] enlève une majorité de types de triche, mais ça amène un coût important pour les serveurs. Au final je pense qu'une majorité de joueurs préfère avoir des logiciels anti-triche sur leur machine (aussi dégueulasse soient-ils) que de devoir payer le surcoût engendré. Ça ne me réjouit pas, mais c'est pour souligner que le problème n'est pas trivial. Je ne cautionne pas ces logiciels, mais je ne vais pas affirmer que le problème est facile à résoudre.

[*] il est amusant de noter que techniquement parlant le cloud gaming (les jeux qui sont rendus coté serveurs, ces derniers envoyant l'image et le son aux joueurs, qui eux envoient juste leurs inputs ) est ce concept poussé à l’extrême, et évite beaucoup de triches possibles (il y a évidemment d'autres problèmes qui viennent avec, comme le besoin d'une très bonne connexion). En pratique le cloud gaming tel que proposé par l'industrie du JV va à l'encontre de ce que j'aime en informatique (le libre) avec une approche jetable des œuvres et ôtant tout le contrôle aux utilisateurs. Mais dans l'absolu un service payant faisant tourner des jeux libres en mode cloud, permettant d'affronter d'autres joueurs (utilisant ce même service) sans triche majeure, est imaginable (on peut rêver).

Si les utilisateurs peuvent avoir le code (sous licence libre, et donc peuvent eux-même le modifier, le redistribuer…) quand il le demande, alors c'est libre. Pas besoin que ça soit public.
Après c'est un peu dommage de ne pas pouvoir, entre autre, jeter un coup d'oeil au code et se faire une (petite) idée de la qualité du soft.

Post intéressant merci.

Je ne suis pas sûr de comprendre ce que tu veux dire par rapport aux plugins en Rust, mais au pire on peut produire des bibliothèques dynamiques en Rust (avec une API C, c'est très utile pour remplacer des bibliothèques existantes par une versions en Rust), et on peut faire du chargement dynamique (j'ai trouvé https://lib.rs/crates/dlopen en cherchant 2 secondes, aucune idée de si c'est la meilleure méthode). J'imagine quand même qu'on doit perdre quelques garanties au passage (et certaines optimisations genre LTO).

Dans les avantages de la chrysalide, je me demande dans quelle mesure ça peut être frustrant avec la solution des lignes de vue que le jeu interdise de se transformer à un endroit mais qu'il l'autorise quelques pixels plus (mais je ne sait pas ce qui est fait comme feedback de la part du jeu, et peut-être qu'en pratique cela ne sera jamais gênant).

Merci pour ta réponse très complète !

Journal très intéressant comme d'habitude !!

Les extra-terrestres étaient limités par le fait qu’ils ne pouvaient pas évoluer à proximité d’humains, ce qui posait problème sur les petits niveaux de jeu. Dans le future, la présence des humains seuls ne sera plus suffisante pour interférer, à la place, les extra-terrestres supposément timides seront empêchés d’évoluer par la connexion visuelle avec les ennemis et leurs constructions.

(disclaimer: je n'ai jamais joué au jeu)
J'imagine bien ne pas être le seul à y avoir pensé, mais quel souci ça poserait (ou posait si ça déjà été essayé) que l'alien passe dans un état de chrysalide où il est particulièrement vulnérable pendant plusieurs secondes, rendant de facto risqué de faire sa mutation à proximité des ennemis ?

La plupart des jeux Battle Royale (…) (exactement ce qu'ils sont, des bousins répétitifs qui utilisent des techniques d'accrochage et de manipulation sur les enfants),

une Switch Lite, ça se trouve à 150€ en occaz' et il y a quelques jeux dessus (Minecraft, Fortnite, Fall Guys, etc)

Fortnite et Fall Guys étant des battle royale j'ai du mal à comprendre ton message et ce que tu conseilles (je me demande si tu ne parles pas de Gatcha).

Voilou:
https://www.youtube.com/watch?v=kJSNTfSUz3o

On parle de temps en temps des possibilités de contributions mais ils sont jeunes et ne s’estiment pas suffisamment à l’aise pour proposer leurs propres créations (déjà qu’en tant qu’adultes ce n’est pas toujours simple…)

Je comprends tout à fait ; après j'ai vu un live (je peux te retrouver le VOD je pense, si ça t'intéresse), d'un papa qui faisait des jeux avec son fils de 8 ans (il en avait 5 ans quand ils ont commencé). C'était des jeux NES avec un un outil proprio (dans lequel on ne programme pas vraiment) mais c'était quand même très inspirant à voir.

Désolé d'avance pour mon commentaire qui apporte sûrement plus de questions que de réponses.

Quelle est ta position personnelle face à la liberté ? J'imagine que ton réfrigérateur ou ta maison n'ont pas leur plan sous licence libre, mais que n'ayant pas vraiment accès à des équivalents libres, tu arrives à vivre avec. Pareil, j'imagine que tu ne lis pas que des livres/BD libres par exemple, peut-être que tu regardes des films, des séries, écoute de la musique pas libre etc…

Je pense que pour la plupart des gens c'est pareil ; si le logiciel propriétaire dont ils ont envie n'a pas un équivalent libre, tu auras du mal à les convaincre que de s'en passer les rendra plus libres. À titre personnel je suis prêt à accepter un logiciel techniquement en dessous s'il est libre, et à me passer de plein de trucs (dont des jeux) parce que ça n'est pas libre ; mais si au final je finis par aller bouquiner un livre pas libre, c'est bien parce que j'ai mis mon curseur "libre" à un endroit qui est tout à fait subjectif. Tout n'est que compromis…

Comme dit plus haut une console de jeu pouurait être un moyen de regrouper tous les trucs propriétaires (mais je pourrais comprendre que ça ne plaise pas).

As-tu déjà parlé avec tes enfants de tes contributions à un jeu libre (parce que pour le coup c'est plutôt cool) ? Et faire un jeu (ou contribuer à un jeu existant) avec eux pourrait être fait en parallèle du jeu dans le monde propriétaire.

Bon week-end !

Oui je suis prêt à payer 50€ pour ce genre de chose, j'ai déjà fait des dons à des jeux Open Source sur Patreon.
Par contre je ne sais pas si je suis prêt à coder tous les dimanches sur des logiciels libres, ça dépend du type de projet, de mes compétences et de mon envie, étant déjà développeur, le week-end j'ai plutôt envie de faire d'autres activités même sur mon ordinateur.

Très bien si tu es prêt à payer pour ça ; et ne t'inquiètes pas, personne ne va te reprocher de ne pas passer tes week-ends à coder du libre ; mes propositions n'étaient que des exemples, pas un ensemble de cases qu'il faut toutes cocher.

Par contre le smartphone devient la norme pour le grand public, et le marché des ordinateurs personnel s’effrite peu à peu et j'ai bien peur qu'un jour on ne puisse plus en acheter de nouveau, ni des pièces de rechange pour réparer les anciens, surtout qu'il y a des écologistes qui commencent à dire qu'un smartphone peut remplacer un PC.

Là je pense que tu es parano. Oui, il y a 20 ans tu avais des tours de PC dans les grandes surfaces, et c'est fini depuis pas mal d'années ; si tu regardes de ce côté uniquement, alors ça fait des années qu'on ne peut plus acheter de PC. Alors qu'en pratique il y a plus de gens qui travaillent sur PC qu'il y a 20 ans ; tu connais beaucoup de développeurs qui codent sur tablette ? De modeleurs 3D ? De monteurs vidéos ? etc…

Peut être que je suis trop pessimiste et que je vois le négatif partout, ce qui est tout à fait possible, mais au global la balance je la trouve négative.

Je ne sais pas de quelle balance tu parles. Il y avait très peu de libre il y a 20 ans (non télécharger des films made in Univers-sale sur son Windows XP—parce que c'est ce que faisait le grand public—ça n'était pas du libre) ; il y en a toujours une minorité. Mais la minorité de libre aujourd'hui elle permet d'avoir un ordi sous un système entièrement libre où tu fais de la 3D, du montage vidéo, de la musique… ce que tu ne pouvais pas vraiment faire il y a 20 ans ; mais oui si tu veux DL le dernier Marvel faut creuser un peu plus. Pas grand chose à regretter pour ma part. Ce qui ne veut pas dire que je ne souhaite pas plus de libre (au contraire ! je veux des jeux libres ! de la musique libre ! des BD libres ! …), juste qu'il y a 20 ans ça n'était pas mieux (le propriétaire est peut-être pire aujourd'hui, mais le libre est mieux ; je préfère me concentrer sur ce dernier point, et éviter le premier le plus possible). Oui, j'avais moins de cheveux blancs, mais ne pas laisser la nostalgie nous aveugler c'est important aussi (ça n'empêche pas de se remémorer les bons moments hein).

Quand j'ai lu ton journal, j'ai d'abord cru que tu t'intéressais plus au tout gratuit qu'à la liberté (celle dont on parle quand on parle de logiciels libres—évidemment la liberté est quelque chose d'assez subjectif…) ; mais comme tu évoques l'achat de musique/jeux sans DRM, ainsi que d'auto-hébergement, il semble que ça ne soit pas juste ça.

Tout d'abord une question (tu peux prendre ça comme une question rhétorique, ne te sens pas obligé de répondre) : qu'es-tu prêt à investir (en temps, en argent) pour la liberté ? Par exemple, paierais-tu 50€ pour participer à la libération d'une petit jeu propriétaire vendu 3€ sur GOG ? Passeras-tu tes dimanches à collaborer à des logiciels libres ?

Ensuite, je te propose de regarder le verre à moitié plein plutôt qu'à moitié vide. Oui, il est clair que la majorité de la société se dirige vers de l'informatique fermée, jetable, centralisée ; c'est triste mais il faudra vivre avec. À côté de ça, les solutions libres sont meilleures que jamais ; le desktop marche généralement tout seul sans avoir besoin de bricoler en ligne de commande, des logiciels propriétaires qui n'avaient pas d'équivalent libre en ont un (ex: Blender n'était pas libre en 2000), on a PeerTube/Mastodon/NextCloud/XMPP etc…

Tu parles d'auto-hébergement, mais avec les connexions Internet d'aujourd'hui, et la disponibilité de mini-ordinateurs à quelques dizaines d'euros, cet auto-hébergement est bien plus accessible qu'auparavant (sans compter qu'avec RISC-V, cela pourra "bientôt"—espérons—être fait avec du hardware libre en plus du logiciel libre).

J'espère que tu trouveras dans ma réponse hétéroclite des des éléments intéressants.

Imagine si des géants de l'informatique comme IBM ou HP écrivaient leur propre OS POSIX, mais en propriétaire, ça serait la fin de Linux !

Hum attendez…

Mouais ; j'ai déjà vu par exemple:

• 2 streamers Twitch (un à Lyon, un en Belgique) jouer à un jeu 3D d'action (pas hyper récent hein, mais un jeu d'action, pas un jeu d'échec) conçu pour la coopération locale, mais le faire à distance avec le logiciel (malheureusement) propriétaire Parsec (qui fait ça, il streame le jeu qui tourne chez un des 2 joueurs pour l'autre joueur) et ça marchait plutôt bien. Et vu que derrière chacun streamait le jeu sur sa propre chaîne, leurs connexions devaient être bien sollicitées.
• 1 streamer jouer à un FPS récent sur un PC Shadow ; il était lui même étonné de ne pas ressentir de latence.

Donc oui, faire tourner un jeu en 4K sur un gros PC et le streamer pour une GameBoy à l'autre bout du monde via un modem 56K ça risque d'être compliqué. Et pareil, si tu fais partie des 0,1% de joueurs qui exécutent des manipulations "frame perfect" tu vas ressentir de la latence. Mais globalement on a dans l'absolu des moyens techniques pour jouer à distance sur un réseau local même à des jeux d'actions ; après existe-t-il des solutions libres actuellement pour le faire ? Je n'en suis pas sûr.

Et alors ? Des gens ont pu se découvrir une passion pour le jeu vidéo en jouant à Wii Sports (en étant tout jeune par exemple), et être ensuite allé chercher des jeux moins mainstream comme Shenmue.

De même que tu peux commencer l'informatique avec des interfaces graphique, et plus tard te mettre au shell.

Voici quelques retour sur ton code pour faire du code plus idiomatique (et donc plus court, lisible, simple et facile à débugger) :

• Tu respectes PEP8 plutôt bien, mais dans les listes arguments (et les listes, les dictionnaires…) il faut un espace après les virgules.

• Évite les index quand un itérateur fait le boulot:

        for j in range(len(history)):
            if (message["email"] in history[j]):
                ...

deviendrait:

        for history_info in history:
            if message["email"] in history_info:
                ...

• Les tests de listes/dictionnaires/tuples… vides peuvent être écrits de manière plus courte et performante:

    if order_info != {}:
      ...

s'écrit plutôt :

    if order_info:
      ...

• Utilise with pour la gestion des fichiers (c'est plus court et le fichier est fermé même en cas d'erreur)

    file = open(..., "w")
    file.write(cont)
    file.close()

gagne à être écrit :

    with open(..., "w") as f:
        f.write(cont)

• Pour les chemins de fichier utilise par exemple os.path.join() qui mettra le bon séparateur suivant la plateforme.

• Les list comprehension c'est la vie:

    lst = []
    for lst3 in history:
       lst.append(",".join(lst3))
    cont = "\n".join(lst)

peut s'écrire :

    lst = [",".join(h) for h in history]
    cont = "\n".join(lst)

Qu'on simplifie alors en :

    cont = "\n".join([",".join(h) for h in history])

Et avec la magie des generator expressions ça peut même être encore plus joli (les [] disparaissent):

    cont = "\n".join(",".join(h) for h in history)

• Peu de chances que l'utilisation de eval() soit une bonne idée (surtout quand on manipule des données externes).

Bon courage pour la suite !

Demain ce sera quoi? Python aura besoin de C, Rust, Golang, Ziglang et le langage de Drew ?

Ou alors c'est comme avec Linux ; au bout de plusieurs décennies un deuxième langage devient accepté, et à ce rythme effréné il faudra attendre 2050 pour un 3ème langage.

L'avenir nous le dira.

C et C++ sont toujours là et doivent toujours lui mettre une grosse fessée niveau perf non?

Pour les classiques micro-benchmarks c'est tout pareil ; tantôt l'un est devant de quelques pourcents, tantôt un autre. En gros si on a le temps et la motivation, on peut être quasi optimal avec C/C++/Rust (et c'est le cas quand ces micro-benchmarks sont écrits : on prend tout le temps d'écrire quelques dizaines de lignes de manière à être optimisé).

Après dans la pratique on a rarement la possibilité de tout optimiser ; et du coup une question plus pertinente est quelle la performance d'un code moyen (parce que dans l'absolu on pourrait tout faire en ASM pour être optimaux ; mais on ne le fait pas pour des raisons évidentes). J'ai bien aimé cet article par exemple qui compare C et Rust (l'auteur dit qu'avec C++ ça serait très légèrement différent):
https://kornel.ski/rust-c-speed

Oui l'image docker qui traîne sur le hub n'est pas "officielle" (dans le sens pas faite par nous) et très ancienne.

Il est prévu de proposer de quoi bâtir son image Docker (et donc choisir son serveur web, son SGBD…), ainsi qu'une image officielle (et donc avec des choix imposés) destinée à tester (et pas à mettre en production) ; mais je ne peux rien promettre sur une quelconque date, cela dépendra du temps qu'on arrive à dégager pour faire ça proprement.

Au passage un gentil membre de la communauté LinuxFr a fait des journaux sur sa dockerisation de Creme.

Comme d'habitude faire une sauvegarde de la base de données et du répertoire media/upload (si vous utilisez les Documents principalement) de manière à revenir à votre installation de 2.1 en cas de gros problème. Attendez quelques jours pour la sortie de la 2.2.1 (rien de méchant de corrigé mais tant qu'à faire…).

Mais sinon tout est fait pour une upgrade sans accroc (avec les commandes d'installation classique migrate, creme_populate, generatemedia). Le Turoriel parle d'une installation depuis 0 ou depuis une 2.1.

Et pour cette version en particulier :

• si vous utilisiez la génération des factures par Latex et que vous souhaitez garder le même aspect, il faudra activer le backend correspondant (vous pouvez le faire a posteriori évidemment) et aller dans la configuration graphique de la facturation pour utiliser ce backend.
• si vous utilisiez les Approches Commerciales dans les activités (peu probable), il faudra remettre le champ correspondant dans les formulaires personnalisés des Activités.

En cas de souci vous pouvez poser vos question sur le forum.

Ce n'est pas arbitraire

c'est arbitraire de décider que c'est LE critère pour décider d'un gagnant, alors qu'il y a à la fois des tas de critères intéressants, et pas besoin de décider d'un gagnant entre 2 outils qui ne résolvent pas les même problèmes ("je dois absolument décider d'un gagnant entre ma fourchette et mon parapluie").

la popularité d'un langage, ce n'est pas la popularité d'une pop star. Un langage utilisé massivement, ça veut dire de la documentation, du support, des bibliothèques, des développeurs…

Une star plus populaire ça veut dire plus de moyens financiers pour les concerts/clips, plus d'opportunités d'avoir des produits dérivés, de trouver des fan arts, de rencontrer d'autre fans et se faire des amis. Donc au contraire c'est un très bon critère pour choisir une star en un sens ; mais là encore ça serait vraiment dommage de choisir uniquement comme ça…

Alors oui, si on pouvait d'un coup de baguette magique transformer le code de Gimp en Rust, et au passage faire que ses contributeurs soient aussi expérimentés en Rust qu'en C, ça serait trop cool.

Mais en pratique c'est déjà souvent compliqué de financer le développement de logiciel libre (Gimp par exemple, et pourtant C est populaire, comme quoi ça ne suffit pas). Donc expliquer aux gens de Gimp "hey passez les 20 prochaines années à réécrire le logiciel, et là peut-être que je vais faire une contribution" illustre bien le problème.