| Les deux révisions précédentesRévision précédente | |
| issue201:actus [2024/01/31 15:29] – [14] auntiee | issue201:actus [2024/01/31 15:36] (Version actuelle) – [15] auntiee |
|---|
| La liste de diffusion des développeurs du noyau Linux a publié des lettres reçues par l'un des développeurs lors de sa correspondance avec Hans Reiser. En 2008, Reiser a été condamné à la prison à vie pour le meurtre de sa femme à la suite d'une querelle et d'une tentative ultérieure de dissimuler le crime (en 2027, Hans pourra déposer une demande de libération conditionnelle). Dans les lettres publiées, Hans regrette ses erreurs d'interaction avec la communauté des développeurs, discute de la dépréciation de ReiserFS v3 dans le noyau Linux 6.6, analyse l'histoire du développement de ReiserFS, mentionne les espoirs associés à la promotion de ReiserFS v4, et explique les solutions techniques mises en œuvre dans ReiserFS v4. | La liste de diffusion des développeurs du noyau Linux a publié des lettres reçues par l'un des développeurs lors de sa correspondance avec Hans Reiser. En 2008, Reiser a été condamné à la prison à vie pour le meurtre de sa femme à la suite d'une querelle et d'une tentative ultérieure de dissimuler le crime (en 2027, Hans pourra déposer une demande de libération conditionnelle). Dans les lettres publiées, Hans regrette ses erreurs d'interaction avec la communauté des développeurs, discute de la dépréciation de ReiserFS v3 dans le noyau Linux 6.6, analyse l'histoire du développement de ReiserFS, mentionne les espoirs associés à la promotion de ReiserFS v4, et explique les solutions techniques mises en œuvre dans ReiserFS v4. |
| |
| Commentant la décision de retirer ReiserFS du noyau, Hans a mentionné que la question de savoir si ce logiciel reste utile et s'il doit continuer à être fourni dans le noyau devrait être décidée par les utilisateurs et les mainteneurs, en tenant compte des réalités actuelles. Il comprend que le fait d'avoir du code ReiserFS dans le noyau crée une charge supplémentaire pour les mainteneurs en raison de la nécessité de tester et d'assurer la compatibilité avec les nouvelles fonctionnalités émergeant dans le noyau, et si le FS n'est plus pertinent, il n'y a pas de raison de continuer à le fournir dans le cadre du noyau. Lors du développement de ReiserFS 4, de nombreuses lacunes de ReiserFS 3 ont été corrigées et la maintenance a été simplifiée, mais cette version n'a jamais été acceptée dans le noyau. | Commentant la décision de retirer ReiserFS du noyau, Hans a mentionné que la question de savoir si ce logiciel reste utile et s'il doit continuer à être fourni dans le noyau devrait être décidée par les utilisateurs et les mainteneurs, en tenant compte des réalités actuelles. Il comprend que le fait d'avoir du code ReiserFS dans le noyau crée une charge supplémentaire pour les mainteneurs en raison de la nécessité de tester et d'assurer la compatibilité avec les nouvelles fonctionnalités émergeant dans le noyau et, si le FS n'est plus pertinent, il n'y a pas de raison de continuer à le fournir dans le cadre du noyau. Lors du développement de ReiserFS 4, de nombreuses lacunes de ReiserFS 3 ont été corrigées et la maintenance a été simplifiée, mais cette version n'a jamais été acceptée dans le noyau. |
| |
| Selon Hans, sa seule demande est d'ajouter un fichier README accompagnant le code de ReiserFS, avant que celui-ci ne soit retiré du noyau, en mentionnant Mikhail Gilulu, Konstantin Shvachko et Anatoly Pinchuk, dont les contributions au développement n'ont pas été reconnues. Ils ont été engagés par Hans et ont développé ReiserFS, mais en raison du caractère effréné de Hans et de ses exigences excessives (Hans pouvait travailler 24 heures sur 24 et attendait un enthousiasme similaire de la part des autres), ils ont quitté le projet, ce qui, à l'époque, a été perçu par Hans comme une trahison, mais avec le temps, il s'est rendu compte que leur décision était justifiée compte tenu des circonstances. | Selon Hans, sa seule demande est d'ajouter un fichier README accompagnant le code de ReiserFS, avant que celui-ci ne soit retiré du noyau, en mentionnant Mikhail Gilulu, Konstantin Shvachko et Anatoly Pinchuk, dont les contributions au développement n'ont pas été reconnues. Ils ont été engagés par Hans et ont développé ReiserFS, mais en raison du caractère effréné de Hans et de ses exigences excessives (Hans pouvait travailler 24 heures sur 24 et attendait un enthousiasme similaire de la part des autres), ils ont quitté le projet, ce qui, à l'époque, a été perçu par Hans comme une trahison, mais avec le temps, il s'est rendu compte que leur décision était justifiée compte tenu des circonstances. |
| 16/01/2024 | 16/01/2024 |
| |
| Les composants nécessaires à la construction du navigateur Chrome pour le système d'exploitation Fuchsia ont été retirés du dépôt du projet Chromium. Il est à noter que la prise en charge de Fuchsia dans Chrome était une expérience qui a été interrompue. Ila été déclaré séparément que la raison de l'arrêt du support est la fin du programme de développement de Fuchsia pour les stations de travail. Le support des composants WebEngine et WebRunner pour Fuchsia se poursuivra, mais un navigateur Chrome à part entière ne sera pas fourni. Le développement futur de Fuchsia se concentrera probablement uniquement sur les appareils grand public, tels que les systèmes domotiques, les cadres photo intelligents et les haut-parleurs. | Les composants nécessaires à la construction du navigateur Chrome pour le système d'exploitation Fuchsia ont été retirés du dépôt du projet Chromium. Il est à noter que la prise en charge de Fuchsia dans Chrome était une expérience qui a été interrompue. Il a été déclaré séparément que la raison de l'arrêt du support est la fin du programme de développement de Fuchsia pour les stations de travail. Le support des composants WebEngine et WebRunner pour Fuchsia se poursuivra, mais un navigateur Chrome à part entière ne sera pas fourni. Le développement futur de Fuchsia se concentrera probablement uniquement sur les appareils grand public, tels que les systèmes domotiques, les cadres photo intelligents et les haut-parleurs. |
| |
| Fuchsia repose sur le micro-noyau Zircon, qui est basé sur le projet LK, étendu pour une utilisation sur différentes classes d'appareils, y compris les smartphones et les ordinateurs personnels. Zircon étend LK en prenant en charge les processus et les bibliothèques partagées, un niveau utilisateur, un système de gestion des objets et un modèle de sécurité basé sur les capacités. Les pilotes sont mis en œuvre sous forme de bibliothèques dynamiques fonctionnant dans l'espace utilisateur, chargées par le processus devhost et gérées par le gestionnaire de périphériques (devmg, Device Manager). | Fuchsia repose sur le micro-noyau Zircon, qui est basé sur le projet LK, étendu pour une utilisation sur différentes classes d'appareils, y compris les smartphones et les ordinateurs personnels. Zircon étend LK en prenant en charge les processus et les bibliothèques partagées, un niveau utilisateur, un système de gestion des objets et un modèle de sécurité basé sur les capacités. Les pilotes sont mis en œuvre sous forme de bibliothèques dynamiques fonctionnant dans l'espace utilisateur, chargées par le processus devhost et gérées par le gestionnaire de périphériques (devmg, Device Manager). |
| |
| Fuchsia possède sa propre interface graphique écrite en Dart à l'aide du framework Flutter. Le projet développe également l'interface utilisateur Peridot, le gestionnaire de paquets Fargo, la bibliothèque standard libc, le système de rendu Escher, le pilote Vulkan Magma, le gestionnaire composite Scenic, les systèmes de fichiers MinFS, MemFS, ThinFS (FAT en langage Go) et Blobfs, ainsi que les partitions FVM. Pour le développement d'applications, la prise en charge des langages C/C++ et Dart est assurée, Rust est autorisé dans les composants du système, Go est utilisé dans la pile réseau et Python est utilisé dans le système de construction. | Fuchsia possède sa propre interface graphique écrite en Dart à l'aide du framework Flutter. Le projet développe également l'interface utilisateur Peridot, le gestionnaire de paquets Fargo, la bibliothèque standard libc, le système de rendu Escher, le pilote Vulkan Magma, le gestionnaire composite Scenic, les systèmes de fichiers MinFS, MemFS, ThinFS (FAT en langage Go) et Blobfs, ainsi que les partitions FVM. Pour le développement d'applications, la prise en charge des langages C/C++ et Dart est assurée, Rust est autorisé dans les composants du système, Go est utilisé dans la pile réseau et Python est utilisé dans le système de compilation. |
| |
| https://bugs.chromium.org/p/chromium/issues/detail?id%3D1509109 | https://bugs.chromium.org/p/chromium/issues/detail?id%3D1509109 |
| |
