GuieA_7 a écrit 689 commentaires

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.

Certes mais vouloir qu'il y ait un gagnant alors que les langages sont sur des segments différents, en utilisant un critère tout à fait arbitraire, tient juste du biais de confirmation. Avec le même sophisme on pourrait dire que c'est PHP qui a gagné…

Il est clair qu'avec son approche plus """élitiste""" Rust sera probablement toujours utilisé dans moins de projets ; mais peut-être qu'il sera dans pas mal de bibliothèque bas niveau (ré-écrire Blender ou Gimp en Rust c'est une perte de temps ; mais des bibliothèques alternatives pour TLS ou jpeg c'est déjà plus réaliste). Voir un gagnant entre Go et Rust là-dedans n'aurait aucun sens.

PS: toi qui aime le jeu vidéo libre, https://veloren.net/ est un projet très intéressant par exemple.

Il n'y a pas une seule stratégie gagnante (il s'agit de gagner quoi d'ailleurs ?). Google (créateur de Golang) utilise Golang ET Rust par exemple.

Faudrait expliquer pourquoi ces deux langages n'ont rien en commun.

Dans l'article il est notamment question de ré-écrire certaines bibliothèques critiques. Or Go a besoin d'un runtime (pour son GC, la gestion des routines notamment) ce qui en fait un mauvais candidat pour cet usage  ; ça pourrait être pire si on utilisait un langage à VM en terme de gros runtime qui vient avec, mais il y a clairement mieux que Go pour ça.

Rust en revanche est un langage qui permet d'aller plus bas niveau (il est totalement utilisable pour écrire un kernel par exemple) ; il ne nécessite pas de runtime et permet d'écrire des bibliothèques qui seront vues de l'extérieur comme si elles étaient codé en C.

À côté de ça, les garanties fortes sur le contrôle des données que donne le système de typage plus puissant (et donc complexe) de Rust est un atout en matière de sécurité (là où en Go il est très possible que 2 routines tapent dans les mêmes données sans que ça soit désirable).

Ce qui aurait été vraiment intéressant c'est un "safe C". Un C compatible à 90% avec l'existant, mais sans les pièges. Mais c'est sans doute plus fun de créer un langage vraiment nouveau.

Vu la popularité de C, si c'était vraiment possible de faire un langage à la fois très compatible et très sécurisé, il est très probable que ça aurait déjà fait. Et des gens très pragmatiques (genre Microsoft, Amazon, Google, des gens guidés par le fun de toute évidence) ne s'embêteraient pas à partir sur un nouveau langage s'ils pouvaient économiser énormément de temps et d'argent avec un tel langage.

Ceci dit, cela ne s'applique pas aux objets qui eux, sont toujours passés par référence.

Du coup c'est un gros "sauf". Et dans la mesure où Rust est utilisable pour écrire des bibliothèques comme si elle était écrite en C, on comprend la présence du concept de pointeur (je comprends qu'on veuille les proscrire dans certains cas spécifiques, mais je préfère dans le cas général l'approche où on garde sous surveillance les quelques blocs unsafe qui traînent).

Si le but est de forcer l'inlining, en Ada, il y a un aspect pour ça et on se passe très bien des macros pour le coup.

Je te rassure Rust sait très bien inliner. Les macros peuvent faire des choses qui ne sont pas possible avec des fonctions (en Rust) :

• Déclarer/définir des types.
• Avoir un nombre de paramètres variable.

Plus de détails ici: https://doc.rust-lang.org/book/ch19-06-macros.html

En fait en Rust on manipule des références la plupart du temps, pas des pointeurs. Si on veut faire des choses acrobatiques comme de l'algèbre de pointeurs, ça sera dans un bloc unsafe pour des raisons assez évidentes (et c'est donc tout à fait évitable en général).

Quand aux macros dont tu parles plus haut (flemme de faire un autre commentaire), il s'agit de macros façons LISP (hygiéniques, gérées par le langage) et pas façon C/C++ (gérées par le préprocesseur, simple remplacement de chaînes sans vérification de syntaxe). Ça permet notamment d'éviter le code boiler-plate de façon plutôt élégante ; mais je veux bien lire tes griefs.

Ça c'est l'ami de mikey !

Ah non c'est le chien de Mickey ; l'ami de Mickey c'est Dingo !

Plutôt que :

for contactId in range(len(contacts)):
    contact = contacts[contactId]

on écrit plutôt :

for contactId, contact in enumerate(contacts):

Mes 2 cents (et bonne année!)

Quand j'ai des calculs un peu bourrins à implémenter, une fuite mémoire c'est un crash assuré donc le résultat est à peu près le même qu'un dangling pointer.

Je ne sais pas ce que le terme technique "bourrins" signifie dans ton monde, mais un dangling pointer peut mener à des résultats faux, mais valides, et sans crash. Donc a un bug que tu ne verras peut-être jamais ; en général on considère que quand un dangling pointer provoque une segmentation fault on a de la chance !

pour moi c'est juste non.

Tu veux dire que comme aucun langage ne garantit l'absence de fuite mémoire, tu ne programmes pas du tout ?

C'est toujours un plaisir de lire tes rétrospectives. Je suis sûr que dans quelques temps tu auras fait de nouvelles choses que tu voudras partager, et que ce n'est pas le dernier bilan (mais si c'était le cas, ce n'est pas grave hein).

Des bisous !

Quel rapport ? Ici, le sujet c'est Rust pour faire un OS

Le rapport c'est que tu n'a pas compris les garanties qu'apporte Rust, alors j'utilise un paradigme plus connu, le GC, en espérant que tu le connaisses mieux, pour te l'expliquer… Mais visiblement tu préfères juste te plaindre que tu as été honteusement trompé.

la memory-safety on nous la sert dès la page d'accueil de Rust alors que pour les fuites mémoires

Pour la bonne raison que les fuites mémoires ne posent pas de problème de memory safety . Ce sont des problèmes, de mémoire, mais qui ne posent pas de souci de sûreté ; les fuites mémoires sont évidemment prises au sérieux, et Rust rend leur présence beaucoup plus difficile.

Donc c'est normal que la sûreté soit mise en avant vu qu'elle est garantie (au revoir les buffer overflows, les dangling pointers, les accès non protégés inter-threads …—et surprise, c'est bien dans le cadre de l'écriture d'un OS), et qu'il faille un peu lire la documentation pour avoir les cas tordus de fuites mémoire.