• # suggestion

    Posté par  . Évalué à 10.

    Ils devraient le réécrire en C.

    Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr

    • [^] # Re: suggestion

      Posté par  (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 27 septembre 2025 à 19:13.

      Toi tu veux relancer une guerre !

      Je n’ai aucun avis sur systemd

      • [^] # Re: suggestion

        Posté par  (Mastodon) . Évalué à 7.

        Pourquoi le C alors qu'il y a déjà une version qui existe ?

        Faisons un Coreutils en Ada à la place, un langage sérieux et moins ésotérique que la bricole rouillé.

        Ada a fait ses preuves dans le complexe militaro-industriel les applications sensibles depuis les années 1980. Et en plus, ça a été conjointement conçu et normalisé par une boite française !

        • [^] # Re: suggestion

          Posté par  (site web personnel, Mastodon) . Évalué à 8.

          Non mais ce n’est pas la hype du moment… On va plutôt demander à une IA de corriger le code rouillé et ça fera un double combo kisscool

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: suggestion

            Posté par  . Évalué à 4.

            En SPARK plutôt alors : https://blog.adacore.com/an-introduction-to-memory-safety-concepts-and-challenges qui a un système d'ownership de mémoire comme Rust, prouvé statiquement. Le post de blog cité dans le lien indique que c'est l'émergence de Rust qui les a poussé à regarder ça sérieusement.

            • [^] # Re: suggestion

              Posté par  (site web personnel, Mastodon) . Évalué à 3.

              Oui, on en avait parlé il y a quelques mois
              gilcot • Journal • la rouille et la comtesse

              “It is seldom that liberty of any kind is lost all at once.” ― David Hume

              • [^] # Re: suggestion

                Posté par  . Évalué à 4. Dernière modification le 28 septembre 2025 à 09:26.

                Quelques * 12 mois, quoi, 2021 … des comptes effacés depuis, la discussion est insuivable.

                • [^] # Re: suggestion

                  Posté par  (site web personnel) . Évalué à 4.

                  Ça arrive, et c'est triste, quand les gens ont peu de respect pour les communautés qu'ils quittent.

                  • [^] # [hs] comment quitter une communauté ?

                    Posté par  (site web personnel, Mastodon) . Évalué à 3.

                    Je n’ai pas compris pour le respect. Il faut un cérémonial particulier ici ?

                    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                    • [^] # Re: [hs] comment quitter une communauté ?

                      Posté par  (site web personnel) . Évalué à 4.

                      Rien ne t'oblige à avoir une politique de terre brûlée / demander à virer tous tes contenus et commentaires quand tu pars. Si tu le demandes, c'est qu'il y a une volonté/raison (qui peut être bonne ou mauvaise).

                      • [^] # Re: [hs] comment quitter une communauté ?

                        Posté par  (site web personnel, Mastodon) . Évalué à 2.

                        Ah oui, je vois ; Je pensais juste à clôturer son compte.
                        Je suppose qu’une bonne raison pour anticiper ce droit à l’oubli c’est qu’il y a des données persos que l’on craint ? J’espère pour ces personnes que le travail va jusqu’au nettoyage des caches des moteurs de recherche et des archives etc.

                        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                        • [^] # Re: [hs] comment quitter une communauté ?

                          Posté par  (site web personnel) . Évalué à 6.

                          À la fermeture du compte (cf aide https://linuxfr.org/aide#aide-fermercompte ) , tu peux demander l'anonymisation et ça règle le cas de la plupart des données persos. Parfois on a des demandes supplémentaires (genre une adresse postale ou un numéro de tél qui traîneraient dans un commentaire ou un contenu). Mais si tu demandes une purge complète des contenus et commentaires, c'est en général qui tu pars soit mécontent soit sans avoir trop réfléchi aux conséquences (que l'on voit à l'origine de ce fil, avec une archive contenant une discussion partiellement caviardée). Dans le dernier cas, on peut expliquer et arriver à un changement d'avis. Dans le cas précédent, c'est juste perdu.

                • [^] # Re: suggestion

                  Posté par  (site web personnel, Mastodon) . Évalué à 4.

                  Bien vu, je n’ai pas vu le temps passer :( ni ne me suis rendu compte des départs (et des arrivés mais cela n’intervient pas ici…)

                  “It is seldom that liberty of any kind is lost all at once.” ― David Hume

            • [^] # Re: suggestion

              Posté par  (site web personnel) . Évalué à 2.

              En Java plutôt, car lui est vraiment mémoire sûr et bien plus connu.

              Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

              • [^] # Re: suggestion

                Posté par  . Évalué à 1.

                Mais n'a rien à voir avec Ada, dans ce contexte

              • [^] # Re: suggestion

                Posté par  . Évalué à 4.

                Après consultation de la liste des outils présents dans coreutils, je trouve que Java est vraiment un bon candidat. Les enchaînements du type cat | cut | tr | sort | uniq ont tout à y gagner.

                • [^] # Re: suggestion

                  Posté par  . Évalué à 4.

                  Une VM pour tous les piper.

                • [^] # Re: suggestion

                  Posté par  (site web personnel, Mastodon) . Évalué à 5.

                  Les enchaînements du type cat | cut | tr | sort | uniq ont tout à y gagner.

                  UUOC spotted !

                  • [^] # Re: suggestion

                    Posté par  . Évalué à 4.

                    <mauvaise_foi.mode=absolue>
                    pas du tout, ça dépend des options de cat utilisées, par exemple, euh… cat -E ?
                    <mauvaise_foi.mode=normale>

              • [^] # Re: suggestion

                Posté par  (site web personnel, Mastodon) . Évalué à 2.

                Mémoire sûre si tu as bien alloué ce qu’il faut. J’imagine bien la prise de tête quand ton head commence à réclamer trop de RAM pour traiter un fichier de trois kilos, ou plante parce-que tu n’as pas bien configuré le Nachat etc.

                “It is seldom that liberty of any kind is lost all at once.” ― David Hume

              • [^] # Re: suggestion

                Posté par  (site web personnel, Mastodon) . Évalué à 3.

                Comme d'habitude, Brendan Gregg a déjà commencé le travail et vous propose dans sa page d'outils spéciaux, une implémentation de la commande echo en java (presque tout en bas de la page). Vous pourrez constater que le code est beaucoup plus court que la version de GNU écrite en C, ce qui démontre la supériorité de Java pour cette utilisation.

        • [^] # Re: suggestion

          Posté par  . Évalué à 2.

          Ada a fait ses preuves dans le complexe militaro-industriel les applications sensibles depuis les années 1980.

          Y compris dans certaines centrales nucléaires françaises.

        • [^] # Re: suggestion

          Posté par  . Évalué à 5.

          Mais non, si c'est pour des outils de base, il faut utiliser du BASIC, c'est évident.

          • [^] # Re: suggestion

            Posté par  (site web personnel, Mastodon) . Évalué à 6.

            Et pourquoi pas du Pascal ?

            Je n’ai aucun avis sur systemd

            • [^] # Re: suggestion

              Posté par  . Évalué à 4.

              Il faudrait ajouter des easter eggs aux coreutils pour justifier l'utilisation du Pascal.

              (je me dis que tu as loupé mon jeu de mots sur "de base" et BASIC :D)

              • [^] # Re: suggestion

                Posté par  (site web personnel, Mastodon) . Évalué à 5.

                Non j'ai pas loupé, mais fallait bien en rajouter à la série (et on n'a pas encore parlé de Fortran).

                Je n’ai aucun avis sur systemd

                • [^] # Re: suggestion

                  Posté par  (site web personnel) . Évalué à 3.

                  Tu viens de le faire.

                • [^] # Re: suggestion

                  Posté par  (site web personnel, Mastodon) . Évalué à 2.

                  Il y en a beaucoup (d’outils de bibliothèque, plus qu’on peut le penser) mais pas core… En même temps, ce langage n’apporte pas grand chose dans des commandes comme head et tail, alors qu’elle peut être un bon candidat pour factor ?

                  “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                • [^] # Re: suggestion

                  Posté par  (Mastodon) . Évalué à 3.

                  • [^] # Re: suggestion

                    Posté par  (site web personnel, Mastodon) . Évalué à 3.

                    À noter que le mème peut s’appliquer à n’importe quel langage qui n’est ni de l’assembleur n saisi via carte perforée : C, Rust, Java, Python, Kotlin, mettez-ce-que-vous-aimez ;)

                    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                    • [^] # Re: suggestion

                      Posté par  (Mastodon) . Évalué à 3. Dernière modification le 28 septembre 2025 à 23:02.

                      Ah non, justement, le langage C, c'est du langage de vrai programmeur ! 😈

                      La preuve dans le paragraphe "THE FUTURE" du manifeste, où le langage C est mentionné:

                      [Even] C programming can be appreciated by the Real Programmer: after all, there's no type checking, variable names are seven (ten? eight?) characters long, and the added bonus of the Pointer data type is thrown in. It's like having the best parts of FORTRAN and assembly language in one place. (Not to mention some of the more creative uses for #define.)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.