Le projet Asahi Linux, pionnier du support Linux sur les puces Apple Silicon, subit un coup dur. Son leader historique, Hector Martin, claque la porte en dénonçant les méthodes de Linus Torvalds, créateur du noyau Linux. Un départ qui intervient après des mois de tensions autour de l’intégration du langage Rust.
Ou pas.
Linus Torvalds se définissant lui même comme un « gentil dictateur ».
de plus, il est connu (par ceux qui s’y intéresse un minimum) que l’intégration de Rust au noyau Linux ne se fait pas sans remous.
P.S. : Etant donnée l’utilisation du terme « libertaire », je me doute de ce qui va suivre, donc je vais prévenir tout de suite : Tout message dérivant vers la politique « générale » sera supprimé.
4 « J'aime »
Je pige pas l’interet d’acheter un mac mais pourquoi pas.
Mais je pige pas l’interet de mettre linux dessus, un support aleatoire niveau driver et non officiellement permis par apple qui peut donc s’arreter a la moindre maj.
Acheter un mac apple silicon c’est utiliser macos. Le monde apple est fermé et vérouillé c’est ainsi.
Mais bon c’est comme vouloir jouer sur mac, certain aime se faire du mal.
Un pc intel lunar lake offrira les prestations (conso, chauffe puissance) similaire a apple avec un linux 100% fonctionnelle et pour les gamers des milliers de jv sont compatible avec proton.
Je le sais car ma boite m’a fournie un tel pc.
Docker fonctionne bien mieux, (le fs de macos est tres mauvais pour docker) que sur le m3 d’un de mes collegues.
Et linux sait installé sans probleme, tous fonctionne et sur nos applications j’ai de bien meilleurs perf que le m3, j’ai cité docker mais aussi pycharm par exemple, pandas ou numpy.
Pour une autonomie similaire.
6 « J'aime »
Le jour ou Linus fermera les yeux ça va être « tempête sur l’échiquier ».
Espérons que le jour ou cela arrivera, il aura filé les rênes à des gens a la tête bien faite.
1 « J'aime »
Eglise au milieu du village : d’un côté on a un gars aveuglé par l’intégration de RUST contre vents et marées, de l’autre, y’a l’patron qui a une vision globale du projet et qui est en capacité d’anticiper de façon plus ou moins détaillée les conséquences sur les périmètres proches de la zone « RUSTée » tant en terme de fonctionnement qu’en terme de maintenabilité.
Quel est le plus important ? Que Linux fonctionne bien ou que Linux soit entièrement porté en RUST pour la beauté du geste ? (et le portage RUST ne garantit pas les non-régressions, au mieux ça rassure les personnes qui ne savent pas gérer l’allocation mémoire correctement dans les programmes)
Bref, le monsieur pro-RUST, ben il forke et bascule tout le noyau en RUST et après on compare et on cause.
4 « J'aime »
Au-delà de la technique, je trouve que le battage de Martin était effectivement indécent et a inutilement déplacé la question de Rust dans le noyau sur le terrain émotionnel/affectif.
Rust n’est pas une religion: c’est un langage moderne qui a ses avantages. Notamment son niveau d’abstraction un chouïa au-dessus de C (qui est tellement proche de l’assembleur…) permettra de gagner du temps dans certaines parties (pilotes graphiques notamment).
Il y a en gros 2 points majeurs qui posent problème: se mette d’accord sur la méthode de passage de paramètres entre Rust-> C et C->Rust, et la problématique d’ajouter un langage pour le noyau (programmer en web fullstack, c’est entre 8 et 12 langages et outils à appréhender - dans le noyau Linux on peut s’y mettre avec 3 outils - et ensuite en gros 20 si on estime nécessaire de connaître le code assembleur de toutes les archis 
)
Mais il y a plein de syntaxe Rust qui permettront d’utiliser de façon transparente mieux les capa de la machine. Sauf que Rust dans le noyau est fortement bridé pour le moment.
1 « J'aime »
Rust au niveau kernel, c’est complètement différent du Rust logiciel classique. Quand on parle de Rust, on parle surtout de son compilateur, qui sait faire du borrow checking. Ça, ça ne marche que si quasiment toute l’application est écrite en Rust.
En effet, dès que le code entre dans une section unsafe, ou, pour le noyau, dans du code en C, le borrow checker est désactivé (forcément). Il y a donc une contamination des résultats de cette section, le compilateur ne sachant pas ce qu’a fait la section, il ne peut plus estimer qui possède quoi et donc la « sécurité » de Rust s’arrête.
Vu la taille du noyau linux, le code en Rust est quasi immédiatement en contact avec du unsafe (typiquement du C ou du code en Rust qui fait des opérations hardware bas niveau) et donc l’intérêt de Rust s’arrête assez vite en fait.
Pour écrire un driver en Rust, il est possible de déclarer des interfaces où l’on ment au compilateur afin que le code du driver soit validé. (On dit au compilateur que telle mémoire et variable est safe, etc). Mais ce mensonge implique pas mal de changement dans le noyau, ce que n’aime pas Linus. Sans ce mensonge, le monde Rust dans le driver n’a que peu d’intérêt, d’où le conflit.
Ceci dit, le comportement d’Hector Martin ressemble beaucoup à un caprice en public. Je pense que c’est bien de rester ferme en face d’un tel comportement, Rust n’est pas la finalité du kernel, mais sa stabilité, sa sécurité et sa performance.
8 « J'aime »
Je trouve que Torvalds a été très soft par rapport à ce dont il est capable.
Dans sa suggestion sur l’origine du problème contre Hector Martin, il signifie qu’il n’apprécie pas qu’il lave son linge sale sur les réseaux sociaux plutôt avec les personnes/équipes concernées.
Et je comprends son point de vue sur la vitesse d’intégration de Rust dans Linux. Il doit ménager la chèvre et le choux dans un noyau de conception assez fragile qui ne tolère pas d’erreurs.
Il y a beaucoup de très gros intérêts dans Linux. il doit être d’une stabilité exemplaire tout en évoluant aussi vite que possible. c’est de l’équilibrisme pour ses équipes de dev.
Linux n’est pas un truc de geeks au fond d’un garage, des dizaines de milliards d’équipements dépendent de ce noyau et au moins autant de dollars.
Asahi est un très bon projet et l’intégration de Rust est à priori nécessaire pour préparer l’avenir, mais aujourd’hui c’est loin des plus hautes priorités du point de vue des développeurs du noyau.
4 « J'aime »
Torvalds a été beaucoup plus cinglant l’année dernière contre les dev de Google au sujet de « leurs optimisations » des systèmes de fichiers.
Il a été forcé de détailler point par point en quoi ce patch n’était pas viable démontrant sa parfaite connaissance de son projet à coups de batte de baseball dans les jambes 
3 « J'aime »
Merci pour cette explication beaucoup plus claire qui permet de voir les motivations des deux « camps ». Parfois on est aussi dans la bataille d’ego et la prudence est généralement plus sûre, mais ça, tout le monde ne l’entend pas.
1 « J'aime »