reno a écrit 3886 commentaires

Il n'y a pas de solution simple

Il n'y en a pas car il y a des inconvénients à l'intégration de Rust dans Linux:
1. Rust n'a pas de spec ce qui va compliquer la vie des développeurs de gcc qui veulent compiler Rust.
2. clang ne supporte pas tout les systèmes que gcc supporte.
3. Linux utilise une version "nightly"(instable) de Rust.
4. un projet multi-langages est + compliqué à gérer qu'un projet "mono"-langage, spécialement quand un des langage est Rust car c'est un langage complexe, Zig/Odin/DasBetterC auraient été probablement plus simple à intégrer mais Zig n'est pas 1.0 (et n'est pas prêt de l'être) et les autres ne sont pas à la mode..

Ce qui ne veut pas dire qu'intégrer Rust dans Linux soit une mauvaise idée, clairement Rust apporte plein de bénéfices ne serait-ce que faire baisser la moyenne d'âge des contributeurs à Linux..

Ce qui est intéressant, c'est qu'avant quand mon smartphone avait 5 ans, j'en avais marre des lenteurs et j'étais pressé de changer, en plus les nouveaux smartphones avaient des écrans plus grands!

Mais 1) mon Galaxy S20 ne me parait pas trop lent, 2) a un écran de taille correcte 3) j'ai atteint la taille max de mes poches, donc tant que la batterie tiendra..

Oui, enfin dans le cas présent, il faut peut être mieux utiliser du code correcte c'est à dire utiliser le type volatile plutôt que de jouer avec les flags de compilation.

Euh personnellement je pense qu'il y a un bug du compilateur là..
Si le compilateur se met a retirer des écritures sur de la mémoire volatile, ça va induire des bugs sur les pilotes!

salut,

j'ai utilisé Perl pendant des années et il est évident que Perl est quasi-mort: c'est à dire principalement utilisé pour maintenir l'existant.
Pour des nouveaux projets comme les nouveaux programmeurs connaissent beaucoup plus souvent Python que Perl..

Avant pour les scripts qui devenaient trop complexe le réflexe était Perl, maintenant c'est Python.

la même ISA

Bah, tant que c'est vraiment la même ISA ça va encore, après tout c'est déjà le cas dans le monde x86.
Mais RISC-V autorise des extensions privées et ça, ça peut être un vrai problème.

Moui, ton premier point est assez discutable: clairement les micro-contrôleurs ont été la cible principale de RISC-V au départ, alors je ne suis pas si sûr qu'il y ai un avantage sur la performance..
Pour ce qui est de la sélection naturelle, pas si sûr que ça marche en pratique, cf Qualcomm qui trouve que les compressed instructions sont une mauvaise idée pour la performance https://www.reddit.com/r/RISCV/comments/170319j/qualcomm_proposal_to_remove_all_16bit/

C'est le seul CPU que je connaisse qui autorise des instructions compressées non alignées..

Bah, le problème avec Pascal c'est qu'il y avait trop de version différentes, alors que C est resté plus "uniforme". L'apparition de gcc gratuit a fait le reste..

Est-ce qu'il n'est pas évident pour tout écologiste que la démographie galopante des 70 dernières années fait grandement partie de l'épuisement de la capacité de l'écosystème à digérer les folies de l'humanité industrialisée ?

A priori non, je me souviens d'un reportage sur un super écolo, qui faisait tout lui-même etc, sa consommation devait être très faible en effet, le reportage finissait en disant qu'il avait 6 enfants !!!.

Pas mal ton idée finale, sur les aides aux familles mono/bi enfants.

Un argument majeur contre X était que c'était trop compliqué et que cela décourageait les contributions, c'est probablement vrai mais

9 ans après que je l'aie vu proposé dans son 1er jet, le protocole de verrouillage de pointeur n'est toujours pas stable.. ah et en 4 ans, la liste des protocoles "stables VS instables" n'a pas bougé non plus ?!? WTF !

le problème est plus compliqué que ça..
Bon après il faut dire que sélectionner une technologie prévue pour de l'embarquer comme base pour le desktop forcément il va y avoir beaucoup de manque au lancement, après même moi qui n'aime pas trop Wayland je n'aurais jamais prévu que le lancement soit aussi anémique..

Vale un language en alpha a même un RAII ou les destructeurs peuvent prendre des paramètres:
https://verdagon.dev/blog/higher-raii-7drl

Ah? Dans ce cas je n'en vois pas l'intérêt D est bien + mature..

Sather avait un GC alors que là on parle d'un C-like.

Interessant l'utilisation de variable immutable sans "tricher" et autoriser le masquage de nom comme le fait Rust.
D'un coté c'est + clair, un nom == une valeur d'un autre je soupçonne que cela induit a creer beaucoup de nom et qu'on finit par faire toto := …; toto2 := … ;

Merci pour ce début de tutoriel

Tu parles du «Jour du Seigneur»? Ça n'est pas nouveau, les groupes de «doctes» qui parlent de choses évidemment fausses comme si elles étaient vraies.

Un bon rappel que les humains ne sont pas très rationnels.. Même quand on a finalement établi des méthodes pour comprendre le monde plus rationnellement, les anciennes théories n'ont pas disparu.

parfois j'ai vu des projets ou certains des "conseils" de la liste étaient appliqués!

Ma vie: j'arrive sur un projet pas petit, des dizaines de développeurs des milliers de ligne de code, on travaille à 2 sur une petite modification et ça core, il nous a fallu 1 journée pour trouver qu'il y avait un problème dans l'ordre d'initialisation des paramètres dans l'appel a un constructeur, on a trouvé le problème tout va bien. Sauf que le lendemain il y a un truc qui me tracasse: mais pourquoi le compilateur ne nous a pas prévenu??

La réponse, c'était [4] aucun warning activé dans le compilateur! Par curiosité, j'active les warnings et hop 600 warnings apparaissent. Là je vais voir mon chef: "on a un problème..".

Bon ayant participé au nettoyage, j'ai vu que sur les 600 warning juste 2 ou 3 étaient des vrais bugs, mais bon quel confort de développer avec les warnings activés!

Sinon 52: les struct c'est pénible: utiliser des entiers partout et fait des typedef pour définir des "types" pour les index, les id, des valeurs en octets ou en bits..

Il y a quand même un truc que je n'ai jamais compris sur le revenu universel, il est universel parce que "c'est plus simple à gérer", vraiment ?
Et l'impact sur l'immigration ?

Note qu'HyperLoop il avait été malin, il a juste fait de la pub pour le concept, il n'a pas investi.
Ce sont d'autres qui ont/vont perdre de l'argent..

Bah, seL4 ça n'est pas juste du C, c'est du C+des preuves formelles qui fournissent plus d'"assurances" que Rust.
Et en plus avec le C, il existe un compilateur "prouvé formellement" CompCert, chose que Rust n'a pas donc tout bug du compilateur Rust peut impacter ta sécurité..

Sauf qu'évidemment pour tout changement de seL4, il faut "refaire" les preuves!
Et KataOS a modifié seL4 sans pour autant faire évoluer les preuves (pour le moment).

Le statut https://nitter.net/LinaAsahi/status/1575343067892051968: Gnome, KDE, YouTube utilisable.
Incroyable de réaliser ça aussi vite.
Par contre ils préviennent que les pilotes sont loin d'être prêts pour faire du jeux vidéos.

Sinon je vous déconseille de cliquer sur la vidéo, la voix est insupportable..

Un truc intéressant de Zig, c'est que les dev essayent d'être "plus correcte" même sur des points qui doivent être bien pénible a implémenter: par exemple le type unsigned en Zig ne wrappe pas, il est exactement comme le type entier signé: soit c'est détecté au runtime (checkers en mode débug) ou a la compilation, soit c'est undefined en mode release (ce qui permet de générer du code plus efficace).
Il y a +%, -%.. pour les opérations qui doivent wrapper.

Par contre j'ai quand même l'impression que Zig se focalise sur l'embarqué au détriment de la simplicité d'utilisation (passer les allocateurs de mémoire partout), Odin me parait bien plus "programmer friendly".

Rust apporte une gestion statique intelligente de la mémoire

C++ le faisait déjà avec les smart pointers.

Pas d'accord, je pense qu'il fait plutôt référence a la gestion des objets en Rust qui est innovante (enfin sauf pour les rares personnes qui ont fait de l'ATS).

Go apporte la notion de VM embarqué
Il n'y a pas de VM en Go :-)

Il y a un GC embarqué. Bon ça n'est pas spécialement innovant un langage avec typage statique générant un exécutable (Eiffel, Delphi, D…) les principales différences sont la simplicité du langage et que ça soit poussé par Google.

et du binaire complet
Là aussi c'est juste de la bonne vieille liaison statique.

Je crois que sur Linux Go ne passe pas par la libc pour faire les appels systèmes donc non pas "juste de la bonne vieille liaison statique".

Pourquoi? Tu aimes coder pour du proprio?

Pas spécialement, mais quand j'investis du temps pour apprendre un langage (avec ses librairies, son système de build, ses outils etc) je veux pouvoir rentabiliser mon temps en l'utilisant "n'importe où".

C'est en GPL3 donc quiconque veut porter ça sur un autre OS est libre de le faire hein.

Ou sinon je peux utiliser un autre langage..
Comme le notait le journal, ça n'est pas ça qui manque!

Si je me rappelle bien Drew Devault n'a prévu de supporter que des OS libres pour Hare!
Je sais bien qu'on est sur LinuxFr mais bon quand j'ai vu ça, j'ai tout de suite classé ce langage dans la catégorie "a oublier"