Discussion :

[devleesch]

Je lis des choses terribles en commentaire.

ChatGPT est sortie en novembre 2022, cela signifie qu'il n'y a aujourd'hui que 2 générations d'ingénieurs qui ont eu accès à ChatGPT pendant leurs études.

En ce qui me concerne, j'ai été diplômé en septembre 2023, je n'ai donc pu avoir accès à cet outil uniquement pendant ma dernière année d'étude.

De plus, ChatGPT n'a pas été immédiatement populaire lorsqu'il est sorti, car hasardeux et peu précis, mes camarades et moi l'ont globalement rejeter a ça sortie.

Mes années 4 premières années d'études supérieures, sont donc inexistence au prétexte que ChatGPT étais accessible pour ma dernière année d'étude (Mes évals étais papier mais tranquille, j'utilisais ChatGPT paper legacy version).

Quant à la GenZ, elle commence de 1997 et ce fini en 2012, ce qui signifie que :
- TOUS les étudiants nés en 1999, ont pu obtenir un master 2 SANS JAMAIS avoir utilisé ChatGPT,
- TOUS les étudiants nés en 2002, ont pu obtenir un BTS/DUT SANS JAMAIS avoir utilisé ChatGPT.
- TOUS les lycéens nés en 2004, ont pu obtenir leur BAC SANS JAMAIS avoir utilisé ChatGPT.

Par ailleurs, je vois beaucoup de développeurs seniors, proches de la retraite, mais pas que, utiliser ChatGPT de manière ostensible, mais passons.

Parlons des formations, les années les plus intéressantes d'étudiant, on était pour moi mes années de BTS, les 3 années qui ont suivi jusqu'à l'obtention de mon BAC+5, on était une vaste blague.
Je n'ai globalement rien appris, et pourtant, j'ai été diplômé avec mention bien.

C'est un problème et on ne peut pas en vouloir à ces étudiants sortis de ces écoles de merde, mais a notre système éducatif en déperdition.

Ne parlons pas non plus du niveau universitaire, a passé leur temps à écrire du C sur papier, et qui se retrouve à faire du dev WEB, sans savoir utiliser correctement des outils basiques et incapables de s'adapter.

Passons sur ChatGPT, a quoi bon s'attaquer à la GenZ, on parle de l'équipe RUST du noyaux Linux.

Quel est le rapport entre nous, à peine sorties d'école et la nouvelle vague de développeur du noyau, certainement un peu plus âgé et donc pas de la GenZ (je rappelle, pas avant 1997, donc 28 ans MAX)?

Les développeurs historiques de Linux commencent à vieillir, c'est un fait, Linus en parlais déjà quand RUST a été introduit dans le Kernel, il serait temps de former les jeunes, a un moment, c'est personne vont mourir ne laissant derrière elle personne pour maintenir Linux.

Par ailleurs, beaucoup d'utilisateurs de Linux sont des jeunes, pour ce qui est de mon expérience personnelle, dans un bureau d'étude de 40 personne 15 ont moins de 30 ans, 10 utilisent Linux, les 25 autres sont tous sur Windows.

Nous sommes beaucoup à êtres vraiment passionné, et a essayer de s'investir ou initier des projets open source, notamment en GO et en RUST.

On attend que ça d'être formé et d'apprendre des plus anciens, mais ces sûr que pour une entreprise, c'est plus simple et surtout moins cher d'utiliser l'IA que de former des jeunes, on vas tous droit dans le mur.
L'école seule ne suffit pas à transmettre un savoir technique et les entreprises n'y aident pas, et ce comportement non plus.

[fdecode]

Nous sommes beaucoup à êtres vraiment passionné, et a essayer de s'investir ou initier des projets open source, notamment en GO et en RUST.

Bien!

On attend que ça d'être formé et d'apprendre des plus anciens, mais ces sûr que pour une entreprise, c'est plus simple et surtout moins cher d'utiliser l'IA que de former des jeunes, on vas tous droit dans le mur.
L'école seule ne suffit pas à transmettre un savoir technique et les entreprises n'y aident pas, et ce comportement non plus.

Il y a néanmoins une dégradation en qualité des personnes formées en sortie du système scolaire et universitaire. Je n'entrerai pas davantage dans une telle discussion à trolls, mais c'est un constat fait avec beaucoup de collègues.

[Uther]

Avec tout ce ramdam autour de C et de Rust, pourquoi ne pas envisager de développer un nouveau Linux entièrement avec Rust ?

Linux c'est des milliers de contributions depuis plus de 30 ans et des drivers pour énormément de matériel différents. C'est pas envisageable de refaire tout en Rust sans perdre beaucoup au passage. Même Microsoft alors qu'il a passé des années à travailler sur Singularity, n'a au final pas pris le risque de remplacer son noyau NT.
Il y a bien des projets de noyaux en Rust, mais ils n'ont clairement pas l'ambition de refaire tout ce que fait Linux. Il faudrait des années et des moyens colossaux.

Tout le code Linux serait entièrement migré en Rust (il y a du boulot) et plus d'embrouille avec les mainteneurs en C car plus de contacts avec eux.

Et on aurait deux noyaux concurrents avec possiblement des problèmes de compatibilité entre eux. Le but du projet est de permettre d'intégrer Rust progressivement sans fragmenter Linux

Aujourd'hui, ce ramdam risque de ne pas attirer ceux qui font du Rust et qui souhaiteraient malgré tout participer au développement de Linux
=> Nouveau projet en partant du début => Nouvelle motivation => Nouveaux mainteneurs

Décourager les gens du projet Rust for Linux semble clairement l'objectif de certains mainteneurs Linux.
Malheureusement repartir de zero n'est pas une alternative si on on veut un OS grand public comparable à Linux : performant et qui supporte tout le matériel générique.

Linux est encore en vie uniquement grâce à une petite poignée de vieux grabataires pré retraités de plus de 50 ans qui codent en C avec un truc qui s'appelle un clavier.
La nouvelle génération Z qui sait pas coder et qui a obtenu son certificat de codage dans une pochette surprise en faisant ses devoirs grâce à ChatGP ne risque pas de pondre un truc utile comme Linux, même en Rust, même en Basic ils n'en seraient pas capables.[...]

Quel superbe ramassis de clichés.
Tous les gens capables de travailler sur le code de Linux ne sont heureusement pas de vieux grabataires, tout comme les codeurs en Rust ne sont pas des jeunot incapables de coder sans IA.
C'est evident que les jeunes qui viennent d'avoir leur diplôme ne sont pas aussi efficace que des développeurs confirmé, mais ça n'a rien de nouveau. Les formation des écoles ne sont par parfaitement en adéquation avec ce qui sera utile dans 100% des cas qui se présenteront au travail, là encore, rien de nouveau, ça à toujours été le cas.

Une fois que tous les anciens seront à la retraite, je pense que le monde va mourir

On disait déjà ça en Grèce 4 siècles avant JC, je vous rassure, le monde est toujours là.

[Invité]

Dans mes souvenirs, Hurd était assez loin d'une version pré-stable en 2000... Mais, je me trompe peut-être. Je m'y suis peu intéressé.

La dernière version de Hurd date de 2016. Sauf erreur, le projet Hurd est l'un des pionniers en matière de micro-noyaux.

Un OS comme ReactOS met du temps à émerger aussi.

Je ne connaissais pas, à tester.

À l'époque des premiers Linux, les utilisateurs étaient prêts à paramétrer eux-même le XWindow au risque de griller leur moniteur (mauvais souvenir pour moi) et se contentaient des 3 disquettes de la slackware.

Heureusement j'ai commencé quelque années plus tard avec la distribution Mandrake Linux.

Je pense que le développement d'un OS (en fait, l'OS + les distributions + les drivers ...) est plus compliqué maintenant.

From scratch, oui. Le "système d'exploitation" GNU de base (glibc, gcc, core utiles, etc) doit compter quelques millions de ligne de code, auxquelles s'ajoutent les 30 millions du noyau Linux. Ce n'est pas quelque chose qui peut être reproduit et maintenu convenablement du jour au lendemain. Avec des LLM spécialisés cependant, ce travail pourrait être facilité à l'avenir.

Selon moi, les projets comme Redox sont techniquement bluffants mais à moins d'être soutenus, utilisés et recommandés par des géants de l'industrie, ils n'ont pas d'avenir à long terme sur le marché. Leur usage demeurera anecdotique, au même titre que d'autres familles d'OS "niche" tel que *BSD.

En conclusion, il vaut mieux contribuer ou s'appuyer sur des projets qui existent déjà. Surtout si ces projets sont répandus et soutenus par l'industrie et une grande communauté de développeurs.

[Invité]

Je lis des choses terribles en commentaire.
Quant à la GenZ, elle commence de 1997 et ce fini en 2012, ce qui signifie que :
- TOUS les étudiants nés en 1999, ont pu obtenir un master 2 SANS JAMAIS avoir utilisé ChatGPT,
- TOUS les étudiants nés en 2002, ont pu obtenir un BTS/DUT SANS JAMAIS avoir utilisé ChatGPT.
- TOUS les lycéens nés en 2004, ont pu obtenir leur BAC SANS JAMAIS avoir utilisé ChatGPT.
.

Je ne sais pas comment cela se passe en France, mais dans bon nombre d'universités suisses, ChatGPT est largement autorisé, voir même encouragé avec des cours de prompt engineering...

Les examens ont en revanche été revus et sont désormais pondérés différemment de sorte à pouvoir certifier les acquis réels des étudiants (par exemple, pour une thèse, la note de soutenance comptera pour deux tiers de la note finale). La plus part des profs avec qui j'ai abordé le sujet m'ont cependant confié être totalement dépassés par les événements et les changements induits par l'IA dans la manière d'enseigner. Ils sont également préoccupés par le niveau effectif des étudiants, qui tend vers le bas.

[RenarddeFeu]

Parlons des formations, les années les plus intéressantes d'étudiant, on était pour moi mes années de BTS, les 3 années qui ont suivi jusqu'à l'obtention de mon BAC+5, on était une vaste blague.
Je n'ai globalement rien appris, et pourtant, j'ai été diplômé avec mention bien.

C'est un problème et on ne peut pas en vouloir à ces étudiants sortis de ces écoles de merde, mais a notre système éducatif en déperdition.

Ne parlons pas non plus du niveau universitaire, a passé leur temps à écrire du C sur papier, et qui se retrouve à faire du dev WEB, sans savoir utiliser correctement des outils basiques et incapables de s'adapter.

On critiquait le système éducatif et parlait de baisse du niveau il y a 30 ans déjà.

Est-ce pire maintenant ? Peut-être, je ne sais pas. Est-ce que les formations étaient de meilleure qualité avant ? Absolument pas !Aujourd'hui comme hier, n'espérez-pas coder votre propre OS grâce à ce que vous avez appris à l'école.

D'ailleurs les vieux de la vieille ont beau jeu de critiquer les nouveaux venus. Ça n'est pas comme si leur carrière avait été fulgurante. Qui plus est, le modèle économique des ESN s'essouffle à cause du multitude de facteurs. La plupart des devs expérimentés n'a pas d'avenir dans le monde qui vient.

[Christophe]

Un OS comme ReactOS met du temps à émerger aussi.
Je ne connaissais pas, à tester.

C'est un projet qui ne "décole" pas, mais refaire Windows, en devant sur certaines parties faire du reverse engineering...

Par contre, ce projet est profitable à Wine avec qui ils travaillent il me semble.

Est-ce que les formations étaient de meilleure qualité avant ?

Il y a toujours un décalage entre ce qui est vu à l'école et en entreprise. Les choses s'améliorent avec l'alternance par exemple. Quand on est 40 en classe, les professeurs peuvent plus difficilement gérer les élèves ayant le plus de difficultés. J'ai un prof d'histoire-géo qui m"expliquait donner des cours de français à ses élèves (problème de compréhension de vocabulaire). Certains élèves n'ont pas de profs pendant des semaines voire des mois, leur niveau ne peut que baisser.

[dee phoenix]

"Avec tout ce ramdam autour de C et de Rust, pourquoi ne pas envisager de développer un nouveau Linux entièrement avec Rust ?"

https://www.redox-os.org/

[Christophe]

pourquoi ne pas envisager de développer un nouveau Linux entièrement avec Rust ?

Parce qu'il y a plus de 27,8 millions de lignes de code à refaire (chiffre de 2020).
Et on ne parle que du noyau.

[Invité]

Parce qu'il y a plus de 27,8 millions de lignes de code à refaire (chiffre de 2020).
Et on ne parle que du noyau.

On peut toutefois diviser ce chiffre par deux ou trois en retirant la prise en charge des anciennes architectures de processeur et du vieux matériel.

[Christophe]

oui mais donc en ne supportant plus ce matériel toujours supporté, et donc faire une régression.

Mais même divisé par 2 ou 3, A quoi bon recoder 9 millions de lignes ?
Rajouter du nouveau code en Rust, éventuellement, mais pas refaire la roue.

[Invité]

oui mais donc en ne supportant plus ce matériel toujours supporté, et donc faire une régression.

Mais même divisé par 2 ou 3, A quoi bon recoder 9 millions de lignes ?
Rajouter du nouveau code en Rust, éventuellement, mais pas refaire la roue.

Une régression à quel niveau exactement ? Les gens qui ont effectivement besoin de faire fonctionner du vieux matériel sur de vieilles architectures peuvent continuer à utiliser le noyau Linux tel qu'il existe actuellement. Que ce soit aujourd'hui ou dans 20 ans.

Un nouveau noyau en Rust, non monolithique, s'appuyant sur Linux et prenant en charge exclusivement du matériel et des architectures récentes devient techniquement réaliste dans la mesure où il n'y a pas à maintenir 20 millions de lignes de code legacy. Et ce n'est pas réinventer Linux, mais reprendre ce qui est utile et fonctionnel.

Le vrai problème est plutôt d'avoir une communauté de développeurs, de sponsors et d'utilisateurs pour exister sur le marché des systèmes d'exploitation.

[Christophe]

Une régression à quel niveau exactement ?

Régression au sens perte de fonctionnalité, enfin ici plus précisément perte d'accès aux mises à jours (correctives et de fonctionnalités) pour les architectures supprimées. Pourquoi ces archis ne sont pas actuellement supprimées ? c'est qu'il y a un intérêt de les garder. Après je ne dis pas qu'il n'y a pas de ménage à faire. Mais ça ne change pas la problématique de tout recoder.

Si on parle de problème d'avoir une communauté de développeurs, on va parler ici d'une ressource limitée, soit on leur fait évoluer le code existant (avec ou sans Rust le prob. n'est pas là), soit on leur fait tout refaire en Rust. A ton avis qu'est ce qui est le plus pragmatique.

Je n'ai rien contre Rust, ni contre les changements, mais c'est pas pour rien que les institutions financières utilisent encore COBOL, un langage obsolète que quasiment personne ici ne doit connaitre ? Tout simplement car refaire tout ça représente des millions d'heures de travail et un risque car ces vieux produits fonctionnent très bien. Bien sûr ça m'étonnerais qu'ils commencent des nouveaux projets en COBOL. c'est un cas intéressant qui montre aussi un problème de stratégie à long terme.

Pour le cas de Linux, on va se retrouver à devoir maintenir du code en assembleur, C, et Rust, avec des ressources hommes limitées. C'est un type de développement qui requiert des développeurs expérimentés. Rust reste jeune, Rust 1.0 date de 2015.

[KiLVaiDeN]

Bientot :

User : Recode Linux en Rust.
Agent IA : Ok. Je commence.

2 jours plus tard :
Agent IA : J'ai terminé. 30M de lignes de code C recodées en Rust. EZ

[Invité]

Régression au sens perte de fonctionnalité, enfin ici plus précisément perte d'accès aux mises à jours (correctives et de fonctionnalités) pour les architectures supprimées. Pourquoi ces archis ne sont pas actuellement supprimées ? c'est qu'il y a un intérêt de les garder. Après je ne dis pas qu'il n'y a pas de ménage à faire. Mais ça ne change pas la problématique de tout recoder.

Si on parle de problème d'avoir une communauté de développeurs, on va parler ici d'une ressource limitée, soit on leur fait évoluer le code existant (avec ou sans Rust le prob. n'est pas là), soit on leur fait tout refaire en Rust. A ton avis qu'est ce qui est le plus pragmatique.

Je n'ai rien contre Rust, ni contre les changements, mais c'est pas pour rien que les institutions financières utilisent encore COBOL, un langage obsolète que quasiment personne ici ne doit connaitre ? Tout simplement car refaire tout ça représente des millions d'heures de travail et un risque car ces vieux produits fonctionnent très bien. Bien sûr ça m'étonnerais qu'ils commencent des nouveaux projets en COBOL. c'est un cas intéressant qui montre aussi un problème de stratégie à long terme.

Je comprends ton point de vue, et il est tout à fait fondé. Et comme tu le soulignes, c'est un problème de stratégie à long terme. Pour moi le pragmatisme consisterait à libérer des ressources développeur, en déclarant les vieilles architectures et matériels obsolètes et dépréciés et cesser de les maintenir sur le plan évolutif ou correctif afin d'encourager les utilisateurs à se tourner vers du matériel plus récent. Cela permettrait aux développeurs de consacrer davantage de temps à rendre le noyau plus sur et préparé pour le futur. L'avenir qui se dessine est tourné vers de nouvelles architectures de pointe et, selon toute évidence, le quantique. Il nécessitera des langages de programmation modernes tels que Rust.

Pour le cas de Linux, on va se retrouver à devoir maintenir du code en assembleur, C, et Rust, avec des ressources hommes limitées. C'est un type de développement qui requiert des développeurs expérimentés. Rust reste jeune, Rust 1.0 date de 2015.

C'est correct, cependant Torvalds a officiellement encouragé l'introduction de Rust au sein du kernel. Avec son experience, il a estimé que les avantages portés par ce language prévalaient sur les inconvénients. Et ce n'est pas un développeur connu pour être influençable ou facile à convaincre sur quoi que ce soit.

[Invité]

Bientot :

User : Recode Linux en Rust.
Agent IA : Ok. Je commence.

2 jours plus tard :
Agent IA : J'ai terminé. 30M de lignes de code C recodées en Rust. EZ

Techniquement, c'est déjà possible. Cependant, ferais-tu confiance à un noyau codé entièrement par un LLM au point de l'installer tel quel sur ta machine ? Personnellement, non. Ni aujourd'hui, ni demain.

[floyer]

Le graal serait une IA qui produit non pas un code équivalent dans un autre langage (si l’IA fonctionne bien, il reproduit les bug ! Ou serait bloqué car des approche C ne sont pas traduisibles en Rust)…. Mais qui réduit drastiquement le coup d’un développement de type SeL4. Ce système est codé en C, mais avec une vérification formelle de conformité à des spécifications de haut niveau.

L’avantage est que si l’IA fournit des preuves bidons, cela sera bloqué par la vérification formelle de preuves (un peu comme un programme généré par IA qui ne complle pas).

[Christophe]

L’avantage est que si l’IA fournit des preuves bidons, cela sera bloqué par la vérification formelle de preuves (un peu comme un programme généré par IA qui ne complle pas).

La compilation n'est pas preuve suffisante. Les failles de sécurités se trouvent sur du code qui compile.

[floyer]

La compilation n'est pas preuve suffisante. Les failles de sécurités se trouvent sur du code qui compile.

Il ne s’agit pas de vérifier si le code compile, mais si l’IA est capable de fournir une preuve formelle de la conformité du code à des spécifications de haut niveau.

Ainsi, il y a une vérification humaine de l’adéquation des spécifications. Ensuite, l’IA fournit le code et les preuves formelles, les preuves formelles sont vérifiées par un outil adhoc (Coq, autre). Ainsi les erreurs ne passent pas inaperçues

C’est le principe avec SeL4… ce micro noyau est spécifié dans un language de haut niveau (moins de risque d’erreur), puis un code C et ses preuves de conformité sont vérifiés. Mais générés à la main, cela demande 7 fois plus d’effort que de produire le code C seul. Si l’IA réalise ce travail, on garderait la fiabilité, mais en diminuant l’effort.

[fdecode]

On disait déjà ça en Grèce 4 siècles avant JC, je vous rassure, le monde est toujours là.

Oui, on aime bien se référer à ces écrits, pour se moquer un peu des vieux qui désespèrent de la jeunesse. Ceci-dit...

Les citations de Platon et d’Aristote sur le sujet (la citation attribuée à Socrate est discutée) ont été publiées à peu près un demi-siècle avant la conquête macédonienne (bataille de Chéronée en -338 => fin de l'indépendance athénienne). En définitive, Platon et Aristote avaient-ils raison de se plaindre de la jeunesse athénienne, peut-être que des travaux d'historiens répondent ou répondront à cette question?