karchnu a écrit 393 commentaires

Et si du code peut être généré automatiquement, c'est qu'il y a un problème au niveau du langage, qui devrait te donner la possibilité de ne pas écrire ce code. Moins de code, moins d'erreurs, moins de temps pour faire le code, moins de temps pour relire, moins de temps pour l'audit, moins de maintenance.

J'ai le même problème avec Java.

Tu t'occupes de développer un système d'exploitation, et visiblement tu le fais en C++. Du coup, je suis très intéressé par avoir un retour de ta part du développement d'un système avec Rust, comme dans le cas de redox os. Si un jour tu as le temps de t'y pencher un peu… n'hésite pas. :)

Les bizarreries au niveau du système de fichiers, comme ceci étant lié à la plateforme, tu peux simplement le gérer lors de la compilation. Aucune surcouche lors de l’exécution. Je ne vois vraiment pas où est le problème.

Dire que des projets C++ se créent tous les jours n’apporte rien, des projets en Brainfuck aussi. Il y a même des gens pour commencer des projets en Javascript.

Je suis assez mitigé sur la question. Si le langage est suffisamment clair et simple, il n’y a pas de raison pour que l’implémentation soit compliquée, et que, dans une certaine mesure, le comportement de deux implémentations diverge. Je ne parle pas de cet exemple en particulier, mais plutôt de manière générale.

De ce qu’on peut en lire sur Wikipédia, la première version d’Objective-C est sortie il y a 32 ans. Après tant d’années à utiliser un langage, on peut trouver des problèmes et souhaiter les corriger, même en passant par un autre langage. J’espère bien que si on trouve des choses à redire sur un langage au point de vouloir en changer suffisamment la syntaxe pour justifier un nouveau langage, on puisse le faire après trois décennies. Rester avec des technos qui sont moins simples, moins efficaces et moins pratiques sous prétexte de l’historique, très peu pour moi.

Je te rejoins sur l’idée que « grosse entreprise ≠ pérennité ». Il y a régulièrement des contres-exemples. En ce qui concerne spécifiquement la programmation dans ces entreprises je n’ai pas assez de recul pour apporter un avis intéressant.

Merci, tu confirmes tout ce que plusieurs personnes avant toi ont pu dire dans ce fil de discussion. :)

Allez, histoire de taquiner un peu : Perl 5 a une rétro compatibilité sur plus de 20 ans. Donc ça se fait ! :D Mais il est clair que c’est l’exception plutôt que la règle.

Je ne pense pas que ce soit pertinent : les langages qui compilent au lancement ne sont pas les plus adaptés à remplacer le C++. Deux catégories, deux outils peu comparables.

Et si on avait un jour un langage orienté système (pas de GC, compilé…) avec une bonne gestion des dépendances et avec une programmation haut niveau façon langages de script (voire Java mais en moins verbeux), alors il est envisageable (selon moi) que nous ayons un remplaçant aux langages dynamiques. Seuls resteront ceux qui, à l’instar de Perl 5, ont été pensés pour un usage spécifique (par exemple la manipulation de texte pour Perl). Bien entendu, je n’exclus pas les hybridations, les attachements personnels ou financiers (investissement sur le long terme) ainsi que l’historique lié aux autres langages qui feront qu’on continuera à les utiliser pendant des décennies. Mais pour des nouveaux projets…

Peut-être qu’il y a un usage extrêmement important et utile des langages dynamiques que je ne vois pas. Mais selon mon point de vue, ils arrivent presque tous à leur terme. Je ne connais pas Python, mais Perl 6 est bien moins pratique pour manipuler rapidement du texte que Perl 5 (surtout avec nos bonnes vieilles habitudes), Ruby glisse doucement vers le compilé avec Crystal… si on arrive facilement à faire de la cross-compilation, je ne vois pas l’intérêt d’un interpréteur.

Bref, je m’égare, je rêve… il est temps de dormir. :)

Donc le langage n’offre pas toujours quelque-chose de simple à utiliser pour certains usages, mais c’est pas grave : il suffit de trouver la bibliothèque qui sera simple à utiliser. Le langage laisse faire des opérations qui peuvent segfault, mais suffit de pas les utiliser (…).

J’ai du mal avec ce raisonnement. Le langage devrait aider le développeur à éviter les erreurs à l’exécution, et proposer des abstractions simples pour les choses simples (le réseau et le système de fichiers, c’est la base).

Aussi, les fonctionnalités dont tu parles et qu’il serait bon selon toi de ne pas y jeter un œil, en vrai on en a besoin pour faire du code propre. C’est bien là le problème. Faire du baby-scripting pour ne pas se taper des maux de tête ça va si c’est pour du code jetable ou du code court (ce qui est assez compliqué à avoir avec du C++), mais dès qu’on veut faire du code propre il faut savoir utiliser les abstractions du langage. Si ces abstractions sont complexes et verbeuses, il y a un problème non pas avec le développeur, mais bel et bien avec le langage.

Je ne vois pas l’intérêt d’avoir des bibliothèques dédiées à faire des GUI dans tous les langages. Un binding C (ou autre) vers des bibliothèques déjà bien (trop ?) fournies en matière de GUI suffit.

Nul besoin de réinventer la roue à chaque nouvelle façon d’écrire du code.

Il y a des concepts super intéressants mais bien complexes qui vont s’ajouter à un langage déjà hyper complexe et assez peu intéressant dès qu’on sort du dogme « perfs à tout prix », mais faudra attendre sans doute quelques dizaines d’années. En attendant, des langages moins prise de tête sortent régulièrement et comblent les très importantes lacunes du C++, à savoir que globalement il tire encore de nos jours des fonctionnalités de lib affreusement étendues et complexes à maintenir telle que la lib boost (à tel point qu’ils se sont fait des outils spécifiques pour gérer la maintenance) voire purement et simplement une reprise des lib du C.

Il y a des simplifications qui arrivent, très bien, elles auraient dû être là il y a bien longtemps. Je ne vois pas l’intérêt aujourd’hui de débuter un programme en C++ s’il n’y a pas un impératif de performances (et avec des bibliothèques déjà développées dans ce but).

Néanmoins, félicitations pour la dépêche. Je pense que cela demande une certaine dose de courage pour continuer à s’investir dans ce langage.

Des applications qui découlent directement de GNUnet j'en connais pas des masses, il y en a des répertoriées sur leur site web. Pour le moment je ne suis pas un vrai utilisateur du système, je me le garde sous le coude pour du développement.

Et c'est ce qu'il y a d'important derrière : GNUnet directement, c'est pour du développement logiciel. Mais si tu regardes des conférences du développeur principal, tu te rendras compte qu'il y a un bon nombre de fonctionnalités déjà présentes et fonctionnelles : ça tourne et t'as des softs. Il m'a dit une fois qu'un de leurs ingé avait fait un twitter basé sur GNUnet, donc ça existe. :)

Je pense regarder de plus près GNUnet dans les prochains temps, j'en ferai sans doute un journal/une dépêche.

Je pense qu'il manque un vrai élément à ta liste : GNUnet. Ce n'est pas à proprement parler un programme, mais un framework qui permet de créer des programmes qui sont acentrés, avec des communications sécurisées et incensurables. Le but est de recréer les outils que nous avons sur internet mais de manière sécurisée et respectueuse de la vie privée, mais également d'aller plus loin que ça, inventer de nouveaux concepts.

Gnunet va plus loin que de simplement proposer un programme, les développeurs cherchent à créer des abstractions qui pourront être utiles dans n'importe-quel autre programme. C'est fait par des chercheurs et des ingénieurs, dont certains sont en France (Inria).

Dans GNUnet, un nouveau système de nommage a été créé pour palier les problèmes du système DNS actuel (centralisation de la gouvernance, censure, …). Le principe est différent de namecoin, mais tout aussi intéressant. Je vous laisse découvrir.

Il y a également un système de routage bien intéressant qui permet de cacher son adresse IP, le réseau est anonymisé au maximum. On peut par exemple (mais ce n'est pas une obligation) ne fait que de la communication ami-à-ami (friend-to-friend) si on est un bon gros parano.

Quelques programmes ont déjà été créés avec ce framework. On retrouve notamment un système de partage de fichiers (acentré, pair-à-pair) avec de la recherche parmis les fichiers (incensurable selon plusieurs modèles d'attaque, dont une volonté propre d'un gouvernement de vouloir censurer).

Bref, je ne peux que vous conseiller de vous lancer dans GNUnet, ça a été conçu sur plus de 15 ans maintenant, par des gens dont c'est le métier, et cela va bien au delà d'un programme.

Pour finir, une petite vidéo (anglais) où Christian Grothoff présente GNUnet : https://www.youtube.com/watch?v=eM4J7ljCExM

Je ne pense pas qu'une autre équipe ne prenne autant la sécurité et surtout l'anonymat aussi sérieusement que ces types. Enjoy !

Une « part de marché » c'est avant tout un concept pour les entreprises qui font de l'argent sur un produit, ça ne s'applique pas à un logiciel basé sur du bénévolat. Les gens qui font des systèmes d'exploitation alternatifs, sauf s'il y a une entreprise derrière qui cherche à le vendre et qui n'a pas encore son public, ne se posera pas la question de la fameuse « part de marché ». On fait un système qu'on considère intéressant, qui apporte quelque-chose de nouveau, qui a une certaine philosophie.

Est-ce que les gens d'Haiku font ça uniquement pour le fun ? Peut-être. C'est aussi probable qu'ils y voient un fonctionnement différent des autres OS, plus intéressant. Quand on se lance dans ce genre de projet, on y voit surtout un intérêt personnel avant de penser aux autres.

Avec quelque-chose comme 10 mots (peut-être même moins) qui sont féminisés sur toute la page, oui tu es pénible.

Nous connaissions déjà le collectif CHATONS, et nous avons effectivement les mêmes objectifs.

Je viens de lire votre manifeste, c'est un long document pour juste dire « ne soyez pas des connards », plus quelques détails techniques sur ce que vous pensez être éthique, soit. Personnellement j'aime bien.

Pour la charte, il y a un élément sur lequel j'ai un doute concernant la légalité : le Warrant Canary. Cela m'étonnerait fortement que ce soit légal de mettre ça en place. Donc en l'état, sans cette clause nous sommes déjà compatible avec CHATONS (ça, et le fait qu'on ne publie pas les paquets installés sur nos machines, mais pourquoi pas).

Les citations présentes ne constituent pas un argument, autre que « regardez, il y a des gens qui disent qu'il faut passer à x86-64 ». À ce compte là je peux aussi citer plein de gens qui disent que la science c'est moins crédible qu'une croyance et qu'il faut qu'on boive notre urine pour guérir de la malaria.

Vous faites du bon travail, et le fait de travailler professionnellement avec des outils libres et en y contribuant si besoin est un excellent moyen d'améliorer ces outils pour tous. J'ai donné un peu d'argent pour le projet en partie parce que je me doutais qu'il y allait y avoir des contributions aux outils, et il n'est pas impossible que je redonne un peu si ça peut aider.

Bonne continuation !

Sauf qu'avec du graylisting, ça peut être un retard de plusieurs dizaines de minutes. Ce ne sont pas les mêmes ordres de grandeur.

Il serait quand même peut-être bon de dire deux mots sur le sujet des conférences, non ? Quel public, quel sujet, un petit mot sur l'organisation… parce que là ça me donne vraiment pas envie. On dirait du clickbait : « Wow, trop bien ! Viens voir ! »

Les mails ce n'est pas fait pour de l'instantané, un mail peut se faire mettre dans une file et devoir attendre un certain temps sans que cela ne soit génant selon le protocole. Donc au moindre graylisting tu vas avoir des utilisateurs qui vont râler que ça marche pas.

Et le fait qu'ils aient fait un patch pour réparer ça sans inclure de solution à base de systemd ne te choque pas ? Ce n'était pourtant pas la solution adaptée au problème selon toi ? Les développeurs de KDE ne semblent pas le voir ainsi, contrairement à ce que tu prétends.

Je pense surtout que tu ne veux pas essayer de comprendre, donc j'arrête la conversation là.

Bon, je vais commencer par l'évident : demander 3 fois la même chose, toujours sur un ton méprisant, ce n'est pas pertinent. Tant d'animosité pour une simple question technique n'est pas nécessaire.

Ensuite pour répondre à la question, le principe même de séparer les systèmes en plein de programmes est une méthode de conception que l'on connait bien depuis facilement les années 70 : ça permet de simplifier les programmes. Le but de séparer l'init de tout le reste est là encore de simplifier les programmes. Un seul bloc de code réunissant des dizaines de bibliothèques et gérant des dizaines de choses différentes est bien plus complexe que de séparer tout ceci en programmes indépendants (oui, avoir juste plein de binaires ne veut pas dire que c'est simple s'ils sont tous dépendants les uns des autres).

Donc là le principe de séparer le système d'init du reste des projets de systemd a pour but une simplification : tu vois le code de l'init, t'as pas besoin de lire un bouquin sur les rouages du reste du système pour le comprendre.

Ethereum n'est pas simplement une monnaie, c'est un mécanisme utilisant une blockchain comme bitcoin mais cela permet de faire plus que simplement une monnaie.