Greboca  

Suport technique et veille technologique

Suport technique et veille technologique

Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.

C’est alors la barrière de la prise en main qui fait peur, et pourtant...

Les logiciels libres

L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.

Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.

Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.

Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.

LinuxFr.org : les journaux  -  Linus répond à la controverse sur R4L (Rust pour Linux)

 -  21 février - 

NB: Ceci est une traduction du courrier de Linus sur la liste de diffusion publique.


Mercredi, 19 Février 2025 à 22:42, Christoph Hellwig hch@infradead.org a écrit:

Le document prétend qu'aucun sous-système n'est forcé d'utiliser Rust. Linus a démontré que c'était faux. Et bien que vous ne le saviez peut être pas quand vous avez écrit ce document, vous le saviez parfaitement quand vous avez posté sur cette liste.

J'avais espoir que cette longue discussion aboutisse à quoi que ce soit de constructif, mais il semblerait que tout va de travers (ou tout du moins, le débat n'avance pas).

Dans les fait, la "pull request" que tu as rejeté NE TOUCHAIT PAS LA COUCHE DMA DU TOUT.

C'était littéralement juste un autre utilisateur de cette couche, dans un sous-répertoire complètement séparé, qui ne changeait pas le code que tu maintiens d'un quelconque manière.

Je trouve pénible que tu te plaignes de nouveaux utilisateurs de ton code, et que tu continue d'apporter ce type d'argument de merde.

Honnêtement, ce que tu as fait, c'est basiquement dire "en tant que mainteneur du DMA, je contrôle comment le code du DMA est utilisé".

Et ça n'est pas du tout comme ça que les choses fonctionnent.

C'est quoi la suite ? Dire qu'un driver en particulier ne peut pas utiliser le DMA, parce que tu n'aimes pas ce périphérique, et en tant que mainteneur tu contrôle qui peut utiliser le code ?

C'est littéralement ce que tu essayes de faire avec le code Rust.

Tu dis que tu es en désaccord avec Rust (dans le noyau Linux), ce qui est acceptable, personne ne t'as jamais obligé d'écrire ou de lire du code Rust.

Mais après, tu prends cette position pour affirmer que le code Rust ne peut même pas utiliser ou s'interfacer avec du code que tu maintiens.

Alors laisse moi être très clair: si en tant que mainteneur tu estimes que tu contrôle qui ou quoi utilise ton code, TU TE TROMPES.

Je te respecte techniquement, et j'aime travailler avec toi.

Et non, je ne cherche pas des gens qui disent "Amen" à tout, et j'aime bien quand vous me reprenez sur mes conneries. Je dis parfois des choses stupides, et il y a besoin de gens pour me tenir tête quand je débite de la merde.

Mais maintenant, c'est moi qui tiens tête à TON débit de conneries.

Donc ce courrier n'est pas à propos d'une quelconque "Politique Rust". Ce courrier est à propos d'un bien plus gros problème: en tant que mainteneur, tu es responsable de ton code, ok - mais tu n'es pas garant de qui l'utilise ni comment il est utilisé.

Tu n'as pas a aimer Rust. Tu n'as même pas t'en soucier. Cela a été clarifié dès le tout début, personne n'est soudainement obligé d'apprendre un nouveau langage, et les gens qui veulent uniquement travailler sur la partie C peuvent très bien continuer à le faire.

Donc pour revenir au coeur de ton propos :

Le document prétend qu'aucun sous-système n'est forcé d'utiliser Rust.

C'est bien vrai.

Tu n'es pas forcé d'accepter du code Rust, ou de te soucier de code Rust dans le DMA. Tu peux l'ignorer.

Mais "ignorer la partie Rust" signifie automatiquement que tu n'as aucun mot à dire non plus.

Tu ne peux pas avoir le beurre et l'argent du beurre. Tu ne peux pas dire "Je ne veux rien avoir à faire avec Rust", et ensuite dans la phrase suivante dire "Et ça signifie que le code Rust que je vais ignorer ne peux pas utiliser les interfaces C que je maintiens".

Les mainteneurs qui veulent s'impliquer dans la partie Rust peuvent le faire, et en étant impliqués, il vont avoir leurs mot à dire sur la conception des "bindings" Rust. Basiquement, ils deviennent également les mainteneurs des interfaces Rust.

Mais les mainteneurs qui choisissent "Je ne veux rien avoir à faire avec Rust" n'auront bien évidement pas besoin de se soucier des "bindings" Rust - mais en conséquence, ils n'auront également rien à dire sur ce qu'il se passe dans la partie Rust.

Donc quand tu changes les interfaces C, les développeurs Rust vont devoir gérer les retombées et corriger les "bindings" Rust. C'est un peu la promesse ici : il y a ce "mur de protection" autour des développeurs C qui ne veulent pas gérer les problèmes avec Rust, ils n'ont pas à se préoccuper de Rust.

Mais ce "mur de protection" va dans les deux sens. Si tu ne veux pas te préoccuper du code Rust, tu n'as rien à dire sur le code Rust.

En d'autres termes : le "personne n'est forcé de se préoccuper de Rust" ne veut pas dire "tout le monde est autorisé à mettre son veto sur du code Rust".

Tu vois ?

Et non, je ne pense pas qu'il y ait besoin que ce soit tout "noir et blanc". J'ai expliqué ci-dessus d'une manière très "noir et blanc" ("devenir mainteneur des "bindings" Rust également" vs "ne pas vouloir se préoccuper du tout de Rust"), mais dans bien des cas je suppose que la ligne sera bien plus floue, où un mainteneur d'un sous-système peut être conscient de l'existence des "bindings" Rust, et disposé à travailler avec la partie Rust, mais sans être très impliqué.

Donc vraiment, il n'y a pas besoin que cela soit "tout ou rien".

-- Linus

Commentaires : voir le flux Atom ouvrir dans le navigateur

par David Delassus

LinuxFr.org : les journaux

LinuxFr.org : Journaux

Une backdoor dans les ESP32 ?

 -  8 mars - 

À titre perso j'aime bien bidouiller l'ESP32. OK ce n'est pas du hardware libre mais ça s'utilise assez facilement, on trouve facilement de la doc (...)


Des points et des points de code

 -  7 mars - 

Sous Gnome, depuis le menu activité on peut accéder à rapidement à un certain nombre de caractères quand on connaît leur nom. C'est pratique pour taper (...)


Nouvelles sur l’IA de février 2025

 -  5 mars - 

Sommaire OpenAI dévoile o3-mini "Deliberative Alignment" ("alignement délibéré" ?) OpenAI dévoile DeepResearch xAI dévoile Grok 3 Anthropic dévoile (...)


Hacker sa pompe de relevage 2 !

 -  2 mars - 

Sommaire Première difficulté : Mise à jour de l'IDE Arduino Watchdog Timer Refonte de l'IHM Utilisation de Preferences.h pour stocker les valeurs de (...)


Loco.sh revient avec macOS à nouveau supporté

 -  28 février - 

Bonjour linuxfr,cela fait un moment que je n'étais venu vous parler de loco.sh, la solution d'industrialisation en bash. Plus d'un an a priori. (...)