karchnu a écrit 414 commentaires

Un jour faudra apprendre à regarder plus loin que la recherche pharmaceutique gérée par de gros lobbies et comprendre que la recherche c'est aussi tout un tas de petits organismes, partout dans le monde, qui n'ont déjà pas tellement les moyens de se payer les abonnements puis les publications puis les conférences.
Et là on ne parle même pas d'un autre type de public qui pourrait vouloir avoir accès aux recherches : les citoyens.

Et la condescendance en invoquant les bisounours, merci mais non merci.

Plusieurs solutions peuvent être envisagées. Dans tous les cas je conseille fortement de chiffrer le disque dur, au cas où. Aussi, même si les serveurs en face sont récupérés, les adresses IP de connexion peuvent ne pas être enregistrées (d'autant plus si de toutes façons l'activité est illégale).

Si on parle d'un point de vue purement technique, on pourrait masquer complètement ton adresse IP (ex: avec Tor).

Cela reste une bonne question, qui mériterait sans doute d'être posée à un avocat pour l'aspect juridique. Faut partir du principe que tu peux aller en prison et avoir à payer de très lourdes compensations…

On a la justice qu'on mérite je suppose…

Bien belle mentalité. Penser aux profiteurs plutôt qu'à ceux qui cherchent des solutions aux problèmes de malnutrition, réchauffement climatique, économies d'énergies, fertilisation des sols, agriculture, pauvreté…

Soutenir la recherche et les chercheurs directement : sci-hub. Tu stockes les papiers chez toi, ils se font proxy vers tes fichiers. T'es invisible (il n'y a qu'eux qui te voient) et tu fournis des milliers (millions ?) d'articles aux chercheurs qui sans ça, doivent payer des fortunes pour accéder à leur propre recherche financée par l'argent public.

Merci pour la grosse blague. :-D
PS: pour ceux qui n'ont pas compris, je ne me moque pas de l'éditeur, juste du fait que cet article soit un copier/coller de celui sur Emacs (je précise, on sait jamais).

Grâce à ton commentaire j'ai évité de faire cette bêtise, j'ai tout backup avant et j'ai désactivé l'extension histoire d'être sûr.

Bonne chance.

Bazel fonctionne que pour un ensemble très restreint de langages et ne fonctionne pas sur BSD (d'ailleurs il suppose par défaut que bash est installé et est dans /bin… ça a l'air bien codé ce truc) donc pour la généricité, on repassera.

Et à côté de ça, Nix, un gestionnaire de paquets. Je ne comprends pas en quoi il répond à la question. J'ai raté un truc ? :-D

J'ai demandé si quelqu'un connaissait un système de build qui se passe de Docker. Que dans ton entreprise le choix s'est porté sur Docker c'est très bien… mais hors sujet. Peu importe les arguments.

Et que veux tu mettre au lieu de Docker, ou même LXC, pour isoler tes builds ?

C'est précisément la question. :)

LXC et Docker sont des solutions très centrées sur Linux. Pour ma part je n'utilise pas (ou peu) Linux. Je préfère me renseigner sur une solution un poil plus générique qui tournerait sur tous les UNIX.

De nos jours, nous avons des systèmes de fichier qui savent gérer des snapshots (lire "une copie d'un répertoire qui coûte rien en temps et en volume de stockage occupé"), ce qui pourrait largement nous aider à créer des rootfs pour un millier de builds sans que cela n'occupe vraiment plus de place qu'avec du Docker. Du coup un "simple" chroot (ou solution équivalente) serait envisageable. Peut-être que ce ne serait pas suffisant, mais tellement plus simple et générique… Docker au fond n'est qu'une abstraction à une solution de ce type, mais en utilisant des fonctionnalités disponibles uniquement sur Linux, et un fonctionnement loin d'être intuitif. Tout ça pour pas avoir à faire un pont réseau, gérer des IP et un le DNS soit-même ?

N'y a-t-il rien de plus simple, réellement, pour faire de l'intégration continue ? Nécessiter Gitlab ou même "que" Docker me semble déjà assez complexe en soit.

Donc en résumé : ça peut casser partout dans ton code, mais le bug viendra de la partie "unsafe" (modulo les bugs dans le langage ou compilateur).

Je trouve ton article intéressant. Tu expliques comment on arrive à Rust et quels sont certains de ses avantages par rapport à C, et bien que d'autres articles existent sur le sujet tu l'appliques sur ton sujet de prédilection : GStreamer. Et c'est un peu là que j'ai du mal.

GStreamer est un code conséquent, les références que tu fais sont parfois floues et le code que tu montres ne m'a pas permis de comprendre intuitivement ce que tu faisais. Et ce n'est pas vraiment un reproche que je ferai à ton article, tu n'as sans doute pas le temps de présenter tous les concepts derrière GStreamer en détail. De ce fait, dès qu'on rentre dans "Écrire des applications GStreamer avec Rust" il devient difficile de suivre sans ouvrir une dizaine d'onglets… ça me rebute un peu. Du coup, je ne sais pas si l'article est trop grand ou pas assez.

En tout cas merci, tu donnes de la visibilité à Rust et à GStreamer. Si en tant que développeur d'outils assez poussés et gourmands en ressources tu considères ce langage, cela lui donne encore plus de crédibilité.

Est-ce que Sympa est plus simple à packager ? De ce que je vois de l'installation de Sympa, il y a une création d'un utilisateur système pour y mettre des fichiers dédiés à Sympa dans le home en incluant des binaires, notamment certains qui sont générés lors de la compilation de modules Perl qui doivent être installés à la volée, ce qui nécessite des bibliothèques de développement pour l'installation…

Pour bien faire il faudrait packager les différentes bibliothèques (ne pas rejouer l'installation à chaque fois, récupérant des bibliothèques dans des versions différentes à chaque fois), ne PAS créer un utilisateur dédié dans /home (c'est juste pas normal de fonctionner de la sorte, vous voyez d'autres softs UNIX demander la même chose ? Non. Et pour cause, c'est pas comme ça que ça fonctionne)… au final il faut patcher l'upstream qui ne respecte pas les conventions, et pas tenter de patcher un gestionnaire de paquets pour qu'il accepte de faire tout un tas de choses qu'il n'est pas censé faire.

Donc finalement, tu dis que mailman est une usine à gaz… moi j'en connais un autre. :-D

Je ne vois pas en quoi "faire tourner de gros sites" implique nécessairement de consommer beaucoup de ressources. D'autant plus à froid, sans une grosse charge. Qu'est-ce qui justifie cela dans votre application ?

La réponse se rapproche fortement de la différence entre un shell et une interface graphique. Tout réside dans l'extensibilité et la facilité d'usage. Étendre un webmail pour qu'en envoyant mon mail j'ai un script qui s'exécute, récupérer le résultat d'une commande, automatiser le reformatage d'un mail type pour afficher directement les informations que je recherche, faire ressortir des mots clés… bon courage.

La liste des possibilités est infinie avec un shell, sans faire de hack particulier, sans écrire du code spécifique à un webmail qui sera périmé à la prochaine version, sans réécrire le code du webmail, en ayant déjà tous les outils du shell à disposition, sans devoir modifier le code côté serveur…

Si je comprends bien, ton navigateur est pensé pour être intégré à Gnome. Donc tu as fait un logiciel qui est plutôt spécialisé… pour un besoin quand même très générique (afficher des pages web).

Ne penses-tu pas qu'il y a de fait un problème sur la conception même du logiciel ? Ne devons-nous pas faire des logiciels les plus génériques possible ? Est-ce qu'une "bonne" intégration à UN bureau justifie un développement spécifique ?

Tu n'as qu'assez peu parlé de l'existant, je ne connais pas du tout le domaine et il me paraît assez bizarre qu'aucune alternative n'existe à celles citées.

Sinon à part ça : ARRÊTE DE ME DONNER ENVIE DE FAIRE DU RUST J'AI PAS LE TEMPS. :'(

Bien que j'utilise mon terminal quotidiennement, je ne m'étais jamais trop renseigné sur les raccourcis possibles. Je connaissais quelques raccourcis présentés ici, pas plus. Ton post a au moins pour mérite de m'y faire penser. :)

PS: j'espère que ces raccourcis sont également disponibles sur d'autres interpréteurs, Bash est quand même peu répandu sur mes machines.

Blender est un logiciel avec énormément de fonctionnalité, il est excellent dans ce qu'il fait.

D'ailleurs, je sais que des gens l'utilisent pour faire du montage vidéo, et j'apprécierai grandement un article à ce sujet.

Je viens de regarder le document, et ce qui frappe c'est avant tout la brièveté des informations fournies, c'est écrit en mode "pense-bête". J'aime bien. Ça change des documents qui réécrivent toute l'histoire de tous les logiciels qu'ils mentionnent ! Après, c'est clairement pas pour les débutants.

Ensuite, je trouve que certaines informations sont assez obsolètes ou du moins je l'espère, parce que j'ai un peu pitié de l'administrateur qui doit encore se taper du sendmail.

Enfin, le fait que ce soit un document à part entière… me gène un peu. N'aurait-il pas mieux valu mettre tout ça dans les documents respectifs de ces programmes, comme des pages de manuel par exemple ? Plus on disperse l'information moins elle est visible.

Pour ma part je garde ce document, je vais lire les quelques parties sur les programmes que je n'ai jamais utilisé. Merci à toi !

J'héberge tout moi-même, je préfère encore ça. Du coup à part le moteur de recherche (ddg), tout est chez moi. Certes mes mails sont en partie chez Google et Microsoft puisque mes destinataires y sont, mais le jour où ils seront prêts à faire héberger leurs mails ailleurs, au revoir tout ce beau monde.

Oh, et openbsd ftw \o/

L'idée de changer un perso en un chat qu'il faut toucher est plutôt sympa, ça fait varier le gameplay.

Par contre gros bémol selon moi, les graphismes. De nos jours, même pour un jeu libre, ça fait cheap. Si un repreneur pouvait se charger de ça… je lui envoie des cœurs ♥ !

Bonjour, merci pour ces explications.

Je me pose une question : pourquoi préférer BTRFS aux autres systèmes de fichiers ? Comme tu l'as indiqué dans ton précédent journal, les utilisateurs voulaient du ext4 par défaut sur opensuse et red hat l'abandonne. Pourquoi donc se lancer dans ce système ?

Question pour les modérateurs : quand un commentaire est "supprimé", pourquoi le commentaire n'est pas réellement supprimé mais remplacé par un message ?

Merci pour avoir pris le temps d'écrire aussi bien une dépêche sur GHC. J'espère que ça intéressera des gens à essayer le langage. :)