Différences

Ci-dessous, les différences entre deux révisions de la page.

--- issue201:actus [2024/01/31 15:20] – [12] auntiee
+++ issue201:actus [2024/01/31 15:36] (Version actuelle) – [15] auntiee
@@ Ligne 715: / Ligne 715: @@
 La sortie du système de reconnaissance optique de texte Tesseract 5.3.4 a été annoncée. Il permet la reconnaissance de caractères UTF-8 et de textes dans plus de 100 langues. Le résultat peut être sauvegardé en texte simple ou aux formats HTML (hOCR), ALTO (XML), PDF et TSV. Le système a été créé entre 1985 et 1995 dans le laboratoire de Hewlett Packard ; en 2005, le code a été ouvert sous la licence Apache et a été développé avec la participation d'employés de Google. Le code source du projet est distribué sous la licence Apache 2.0.
-Tesseract comprend un utilitaire de console et la bibliothèque libtesseract pour intégrer la fonctionnalité OCR dans d'autres applications. Les interfaces GUI tierces qui supportent Tesseract incluent gImageReader, VietOCR et YAGF. Deux moteurs de reconnaissance sont proposés : un moteur classique qui reconnaît le texte au niveau des modèles de caractères individuels, et un nouveau moteur basé sur l'utilisation d'un système d'apprentissage automatique fondé sur un réseau neuronal récurrent LSTM, optimisé pour reconnaître des chaînes entières et permettant une augmentation significative de la précision. Des modèles entraînés prêts à l'emploi ont été publiés pour 123 langues. Pour optimiser les performances, des modules utilisant OpenMP et les instructions SIMD AVX2, AVX, AVX512F, NEON ou SSE4.1 sont proposés.
+Tesseract comprend un utilitaire de console et la bibliothèque libtesseract pour intégrer la fonctionnalité OCR dans d'autres applications. Les interfaces GUI tierces qui supportent Tesseract incluent gImageReader, VietOCR et YAGF. Deux moteurs de reconnaissance sont proposés : un moteur classique, qui reconnaît le texte au niveau des modèles de caractères individuels, et un nouveau moteur basé sur l'utilisation d'un système d'apprentissage automatique fondé sur un réseau neuronal récurrent LSTM, optimisé pour reconnaître des chaînes entières et permettant une augmentation significative de la précision. Des modèles entraînés prêts à l'emploi ont été publiés pour 123 langues. Pour optimiser les performances, des modules utilisant OpenMP et les instructions SIMD AVX2, AVX, AVX512F, NEON ou SSE4.1 sont proposés.
 https://github.com/tesseract-ocr/tesseract/releases/tag/5.3.4
@@ Ligne 776: / Ligne 776: @@
 /01/2024
-Après six mois de développement, la nouvelle version 1.33 du paquet wayland-protocols a été publiée, contenant un ensemble de protocoles et d'extensions qui complètent les capacités du protocole Wayland de base et fournissent les capacités nécessaires à la construction de serveurs et d'environnements utilisateurs composites.
+Après six mois de développement, une nouvelle version 1.33 du paquet wayland-protocols a été publiée, contenant un ensemble de protocoles et d'extensions qui complètent les capacités du protocole Wayland de base et fournissent les capacités nécessaires à la construction de serveurs et d'environnements utilisateur composites.
 Dans la nouvelle version, le protocole « linux-dmabuf » a été transféré dans la catégorie stable, ce qui assure le partage de plusieurs cartes vidéo utilisant la technologie DMA-BUF (permet de créer des wl_buffer basés sur DMA-BUF). Un nouveau protocole « ext-transient-seat » a été ajouté et placé dans la catégorie « staging ». Ce nouveau protocole peut être utilisé pour créer des sessions indépendantes temporaires (seats) conçues pour être utilisées avec des périphériques d'entrée virtuels mis en œuvre à l'aide des protocoles « virtual_keyboard_unstable_v1 » et « wlr_virtual_pointer_unstable_v1 ». Par exemple, lors de la mise en œuvre de la capacité à se connecter à un bureau à distance, le protocole vous permet de créer une session distincte pour chaque utilisateur à l'aide d'un clavier et d'une souris virtuels.
@@ Ligne 793: / Ligne 793: @@
 /01/2024
-Nate Graham, un développeur QA sur le projet KDE, a publié un rapport sur les préparations pour la sortie de KDE 6 prévue pour le 28 février. La base de code de KDE Plasma 6.0 et KDE Gears 6.0 a été dérivée dans un dépôt séparé, et la branche principale a commencé à accumuler des changements pour KDE Plasma 6.1 et KDE Gears 24.05.
+Nate Graham, un développeur AQ sur le projet KDE, a publié un rapport sur les préparations pour la sortie de KDE 6 prévue pour le 28 février. La base de code de KDE Plasma 6.0 et KDE Gears 6.0 a été dérivée dans un dépôt séparé, et la branche principale a commencé à accumuler des changements pour KDE Plasma 6.1 et KDE Gears 24.05.
 https://pointieststick.com/2024/01/19/this-week-in-kde-auto-save-in-dolphin-and-better-fractional-scaling/
@@ Ligne 835: / Ligne 835: @@
 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.
@@ Ligne 856: / Ligne 856: @@
 /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 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