roptat a écrit 9 commentaires

  • [^] # Re: Projet très jeune en recherche de crédibilité

    Posté par  . En réponse au journal PeerTube est dispo en v1.0. Évalué à 1. Dernière modification le 16 octobre 2018 à 14:08.

    Je n'arrive pas à trouver le lien en question. C'est où ?

  • # Guix

    Posté par  . En réponse au journal Une image de base docker. Évalué à 10. Dernière modification le 09 août 2018 à 14:50.

    Vu qu'on parle de docker et que chacun y va de sa solution préférée, je voulais vous parler de Guix, qui propose une méthode pour exporter un conteneur docker. Si je veux un conteneur avec emacs, voilà ce que je tape :

    guix pack --format=docker emacs
    

    Le résultat de cette commande est le chemin vers un conteneur docker qui contient emacs et ses dépendances, et rien d'autre. On peut alors charger le conteneur : docker load --input /gnu/store/.... Cette méthode a aussi l'avantage d'être reproductible : en indiquant cette commande et la version de guix utilisée, il est possible pour n'importe qui de reproduire le conteneur au bit près, et de vérifier que je n'ai pas triché. Et se sera toujours possible même dans 10 ans (avec toutes les failles de sécurité, évidemment).

    En dehors des paquets disponibles dans la distribution, on peut aussi créer ses propres paquets. Pour reproduire dans ce cas, il faut aussi évidemment distribuer la recette avec le conteneur, la commande et la version de guix utilisée.

    Ainsi, on obtient facilement un conteneur dont le contenu est traçable, reproductible et pérenne. Les conteneurs à coup de base « debian stable » et de « apt-get update » ont déjà perdu. Alors qu'en modifiant peu de choses, quelques options de la ligne de commande ou la version de Guix, on obtient un nouveau conteneur qui diffère du premier de manière compréhensible. Par exemple, on met à jour emacs et ses dépendances, on ajoute un logiciel supplémentaire, on change une option à la compilation d'emacs ou on remplace emacs par vim.

    Certes, la plupart des conteneurs sont toujours exécutables après des années, mais si on perd la capacité de les recréer (les recompiler) et de les modifier, je pourrais troller et poser la question : est-ce vraiment de logiciel libre dont on parle ?

  • # Un missile en Open-Source

    Posté par  . En réponse au journal Des armes en Open-Source. Évalué à 10.

    Et pendant ce temps-là, des danois fabriquent un missile en open-source : https://copenhagensuborbitals.com/

    Bon en réalité ils comptent envoyer une fusée dans l'espace, mais c'est pas si différent d'un missile, si ? Au passage, ils voulaient faire un essai ce week-end mais ils n'ont pas pu faire libérer l'espace aérien. C'est reporté au matin du 4 août, rediffusé en direct !

  • [^] # Re: Merci pour la rédaction

    Posté par  . En réponse à la dépêche Linux From Scratch 8.2 : C’est vous qui faites !. Évalué à 8.

    Salut,

    j'ai maintenu un système LFS sur mon PC pendant un peu plus d'un an, mais ça a fini par devenir très chronophage. J'avais créé mon propre gestionnaire de paquets et scripts pour gérer le système (notamment générer un initrd). Mes scripts sont disponibles sur framagit. J'ai fini par abandonner simplement parce que je n'avais plus trop le temps de maintenir une distribution à moi tout seul. Après j'imagine qu'avec des mises à jour moins fréquentes et des besoins plus simples, c'est possible. Finalement j'ai appris énormément sur la gestion de paquets, la maintenance de logiciels et l'intégration, l'administration et tout ce qui se trouve « sous le capot ». Maintenant je me suis assagi et je suis contributeur sur un projet existant avec un peu plus de monde que moi tout seul. Ce que j'ai appris me sert toujours.

    Bref, ça se fait très bien, mais c'est plus motivant quand on est plusieurs avec une vision commune.

    Il me semble que d'autres utilisent simplement la version stable sans vraiment la maintenir et recommencent tout lorsqu'une nouvelle version sort. Ça demande moins de boulot aussi.

  • [^] # Re: Quels outils ?

    Posté par  . En réponse au journal On ne contribue pas que du code. Évalué à 2.

    Merci pour les liens ! Ces trois outils sont tous en ligne, pour le traducteur, n'est-ce pas ? Comment fait le programmeur pour générer les fichiers à traduire, et sous quel format, du coup ?

    Pourquoi avoir choisi des outils maison, plutôt que des outils existants ? Typiquement, j'ai l'impression que tout pourrait se trouver sur pootle, non ? Et je voudrais pas dire, mais votre version de pootle est un peu ancienne :p

    La deuxième question, c'est pourquoi le format fournit par ICU. Je ne connais pas ce format, donc je me demande quelle différence il y a entre ça et gettext ?

  • [^] # Re: Quels outils ?

    Posté par  . En réponse au journal On ne contribue pas que du code. Évalué à 2.

    Pour LFS, on utilise po4a, ça marche plutôt bien. J'ai un script qui tourne chaque nuit pour récupérer les derniers changements et les proposer sur notre instance pootle. Ce qui est dommage, c'est que ça fait une instance en plus (donc encore un compte) et pour l'instant ça n'est utilisé que pour le français.

    Je suis aussi curieux de savoir s'il y a d'autres outils, et s'il y a des exemples d'intégration dans le dépôt amont, ou si c'est tout le temps géré à part comme pour LFS.

  • [^] # Re: Chez Wikimedia …

    Posté par  . En réponse au journal On ne contribue pas que du code. Évalué à 1.

    Oh, incroyable ! Voilà encore plein de liens que je ne connaissais pas. Et j'adore l'idée d'utiliser le wiktionnaire comme un glossaire (et plus avec synonymes et antonymes). Justement l'un des points que je reproche aux différentes plate-formes, c'est d'être fermées sur elles-mêmes. Pas moyen de partager automatiquement les glossaires ou les traductions alors que ça serait bien pratique. Par exemple pour OSM, on peut imaginer que diverses applications qui font GPS vont avoir la chaîne « tournez à gauche » ou encore « restaurant végétarien ». Ça ce sont des termes faciles, mais quand on commence à creuser, on a des trucs assez difficiles à traduire et il faut faire attention à ce que ça soit traduit partout pareil, sinon on ne s'y retrouve plus.

    Alors oui, les plate-formes permettent d'exporter et importer les glossaires à la main, mais c'est pénible et on ne sait jamais si c'est à jour entre les projets.

  • [^] # Re: Localization

    Posté par  . En réponse au journal On ne contribue pas que du code. Évalué à 2.

    Salut !

    merci pour le commentaire. En effet, la localisation (régionalisation ?), c'est ce que j'appelais la traduction : je fais attention à bien traduire les dates, unités, et à utiliser des exemples plus parlant : par exemple, quand en anglais on a « lancez “export LANG=en_US.UTF-8” », je remplace par fr_FR.UTF-8.

    Par contre, je trouve que la « traduction machine avec post édition » est compliqué. Ça marche bien assez souvent, mais parfois ça donne des tournures bizarres ou peu satisfaisantes et je me retrouve bloqué à pas savoir quoi faire parce que la proposition éclipse tout ce que j'aurais pu trouver par moi-même. Par contre j'utilise de la traduction automatique pour les trucs vraiment répétitifs (mais sans relecture du coup). Ensuite il faut trouver des relecteurs et j'ai l'impression que c'est encore plus rare que les traducteurs :)

    Tu parles de traducteurs et relecteurs spécialisés, est-ce que tu penses à quelque chose en particulier ?

  • [^] # Re: passé a linux recement

    Posté par  . En réponse au sondage En quelle année êtes-vous passé(e) à GNU/Linux (ou autre système libre) ?. Évalué à 10.

    Oh non ! Pas ça !

    LANG=C, surtout si c’est mis au niveau du système, ça change la langue de tout, et ça ne permet pas la prise en charge correcte de l’UTF-8. Utiliser LANG=en_US.UTF-8 c’est bien mieux : c’est toujours de l’anglais et on peut tout de même lire le français.