Jean-Cédric Chappelier et moi-même avons lu attentivement vos commentaires concernant le projet et il nous paraît important d’y répondre en détail.
Tout d’abord, il y a très peu de remarques qui concernent les objectifs d’apprentissage. Ceux-ci paraissent bien compris. Ceci est en soi une bonne nouvelle car nous sommes conscients que ce projet apparaît tôt dans le curriculum, alors que les bases théoriques des systèmes d’exploitation n’ont pas encore été couvertes, et en particulier la relation entre mémoire virtuelle (les pointeurs) et les systèmes de fichiers (les offset dans le .cvks). Par ailleurs, vous avez des niveaux d’expérience très divers avec les environnements Linux.
L’essentiel de vos remarques se concentrent sur trois points: la charge de travail, le degré de spécification du projet, et les environnements.
Concernant la charge de travail: beaucoup d’entre vous estiment que le binôme passe souvent plus de 8h par semaine pour le cours estimé pour 2 crédits ECTS, ou alors que le cours correspondrait plutôt à 4 crédits ECTS.
Les projets peuvent effectivement être chronophage. Il nous paraît important de relever que 32% des binômes ont passé moins de 8h par semaine sur le projet (l’histogramme se base sur la période de semaine 04 à 09 c’est-à-dire “submit2”) et que 70% des binômes ont passé moins de 12h par semaine pour cette période (ce qui correspondrait à 3 ECTS).
Par ailleurs, vous avez dans votre grande majorité rendu un travail très complet puisque 86% des binômes ont accompli le 100% des tests “end-to-end”; et 76% des binômes ont eu le 100% des tests unitaires. Félicitations ! Vous avez certes investi de nombreuses heures dans ce projet, mais avec des résultats qui vont au-delà de ce qui était attendu.
Concernant la spécification du projet, certains estiment que les énoncés sont vagues / indéfinis etc. Nos instructions se veulent non ambiguës, ce qui ne veut pas dire que tout est spécifié de manière directive ou explicite. Il s’agit d’un choix pédagogique assumé qui implique une bonne part de réflexion et d’apprentissage de votre part pour résoudre les étapes. Ce projet est clairement moins directif que vos projets de BA2, mais il est, par contre, plus dirigé et directif que les projets que vous ferez durant les semestres à venir, et qui auront un plus grand degré de liberté. Il s’inscrit donc dans la progression de vos études. Dans quelques rares cas, nous avons effectivement clarifié certains éléments de l’énoncé (et/ou dans Piazza), mais il s’agit, de notre point de vue, de cas exceptionnels et mineurs.
Concernant les environnements de travail: il s’agit d’un projet “système” portable, cependant conçu et validé dans un environnement Linux, utilisant les outils et les méthodologies qui vous accompagneront dans votre carrière (CLI, git, Make, Docker, VM, etc). Au fil des années, nous avons documenté des solutions alternatives, tout en précisant qu'elles n’étaient pas supportées; et en parallèle, nous avons introduit l’utilisation des containers docker pour le “make feedback” afin de garantir une correction uniforme. Nous avons remarqué, de manière empirique, que beaucoup de temps était perdu par certain.e.s sur des questions de configurations. Le cas du Macbook avec processeur M1 est particulier; en théorie, Apple offre via Rosetta un environnement d’émulation x86 sur les processeurs ARM; en pratique des incompatibilités ont été détectées au milieu du semestre avec address sanitizer. Personne dans l’équipe d’enseignement n’avait le hardware à disposition, et nous n’avons pu répondre à cette problématique très spécifique.
En conséquence, nous avons commencé un processus de réflexion dans une logique des années à venir. Par exemple, nous pensons:
simplifier les 3 premières semaines en réduisant la quantité des rendus afin de réduire le stress associé aux premiers rendus, mais en assurant toutefois que les bases d’outils (git, Make, etc) soient bien maîtrisées ;
guider plus fermement vers un environnement Linux (que l’essentiel de vos PCs peuvent installer dans une MV) ;
fluidifier les processus de “make feedback” et “make check” afin de simplifier le debugging interactif.
Quant au projet de l’année prochaine, il sera par définition différent de celui-ci; cependant nous restons intéressés par des remarques spécifiques précises concernant divers handouts de « CKVS »
Dans cette optique, nous avons prévu de rencontrer les délégués de classe peu après la fin du semestre afin d’échanger avec eux. Nous vous prions de leur remonter toutes vos impressions à la fin du projet.
Bien à vous,
Prof. Edouard Bugnion
