Alexandre Belloni a écrit 117 commentaires

Ce qui est incroyable dans cette réponse, c'est de défendre la position qu'il faut absolument apposer GNU à Linux en passant sous silence tout le reste, GNU n'a jamais représenté 100% du userspace et il y a toujours eu des composants BSD donc pourquoi insister sur GNU?

Que tu aimes ou pas, c'est un fait et accoler GNU à Linux est de la propagande de la FSF pour se donner une importance que l'organisation n'a pas.

D'un autre côté, qu'est-ce qu'il reste vraiment de GNU dans une distribution moderne basée sur le noyau Linux à part la glibc?

Non, il faut bien corriger la dépêche:

Le temps UT1 est physiquement instable, la rotation de la planète ayant tendance à accélérer depuis la mise en place du temps universel.

la rotation de la terre a tendance à décélérer depuis la mise en place de UTC: la seconde TAI (et donc UTC) est basée sur la vitesse de rotation moyenne de la terre entre 1750 et 1892.

Pire, la rotation est actuellement en train de décélérer, et rien n'a été prévu pour supprimer une seconde à UTC.

C'est bien l'inverse, c'est parce qu'elle accélère qu'il faut supprimer une seconde.

Sans compter que les systèmes savent gérer le changement d'heure, qui lui impose un retour en arrière et des trucs vraiment pas propres quand on "gagne" une heure (genre, il est deux fois 2h30 du mat dans la même nuit, là pour le coup le temps revient vraiment en arrière).

Non, du point de vue du système, le changement d'heure s'effectue comme un changement de timezone, l'heure du système reste en UTC et c'est l'offset qui est mis à jour. Le temps UTC reste donc continu, ça n'est pas le cas avec les secondes intercalaires.

Les horloges matérielles (composants "real time clock") comptent toujours en années, mois, jours, etc. Les composants compatible avec l'an 2000 ont ajouté… 1 bit, pour dire si on est au XXè ou au XXIè siècle. Il est utilisé pour le calcul des années bissextiles (qui ne semblent poser problème à personne, elles? pourtant elles sont là pour une raison assez similaire)

Ça n'est pas exact, il y a de nombreuses RTCs qui sont de simple compteurs de secondes.

Le problème des années bissextiles et celui des secondes intercalaires est complètement différent.
Pour les années bissextiles, on décide simplement qu'un jour est le 29eme du mois de février mais ce jour fait bien 84600 secondes et donc le temps est continu. Pour les secondes intercalaires, on rejoue deux fois la même seconde pour obtenir un jour de 84601 secondes et le compte n'est donc plus continu.

Le temps UT1 est physiquement instable, la rotation de la planète ayant tendance à accélérer depuis la mise en place du temps universel.

C'est bien l'inverse, la rotation de la terre a tendance à ralentir à cause des effets d'attraction luni-solaire et elle s'est accélérée inexplicablement ces dernières années, D'où le besoin de retirer une seconde intercalaires

Apparemment non: https://www.youtube.com/watch?v=7UfiCa244XE

La bonne expression était tu manges en suisse ;)

https://fr.wiktionary.org/wiki/en_suisse

Ça fait 8 ans que j'utilise: https://www.cherry.co.uk/cherry-strait-3-0.html

A part l'argent qui se décolore et les touches S D etC qui sont effacées, rien à redire.

Pour être exact, le noyau utilise 64bits pour l'heure système depuis longtemps. Et du côté interfaces userspace, le travail s'est terminé récemment.

Le reste du travail va plutôt concerner les libc et le reste de l'espace utilisateur.

Linux choisit la compatibilité du code source recompilable sur plein d'architectures, mais va donc lancer un programme propriétaire pour Linux 2.6 sur un noyau actuel !

C'est tout simplement faux, ça n'est pas un problème de noyau. Le noyau Linux a pour politique de ne pas casser l'ABI avec les binaires. Le problème du vieux programme propriétaire, ça va être le reste de l'espace utilisateur et notamment la libc, les libs graphiques, etc… Mais un binaire propriétaire compilé en statique qui fonctionnait sur un noyau 2.6 doit continuer à fonctionner sur un noyau récent. Sinon, c'est un bug du noyau et il doit être corrigé.

D'ailleurs, l'article d'origine ne parle de pas de problème avec le noyau.

Pour PCW, tu indiques: "manque juste la ref de la carte mère, comme partout ailleurs"

En fait, tu cites exactement cette référence plus tôt: "N240WU, N141ZU et N141WU". Ce sont des PCs clevo (https://www.clevo.com.tw/clevo_prodetail.asp?id=1155&lang=en) qui sont revendus. Donc tu peux chercher clevo et tu trouveras d'autres revendeurs.

J'ai un N141ZU acheté chez schenker: https://bestware.com/en/schenker-slim-14.html
Je l'aime bien mais il est assez bruyant par rapport à mes Dell précédents.

Mais toutes les personnes concernées par le mail en question (les mainteneurs donc) avaient suffisamment de contexte pour ne pas le comprendre de travers. Il n'y a jamais eu de Maintainer Summit qui n'était pas accolé à une autre conférence ça n'aurait aucun sens économique de le faire.

pendant que lui glanderait à Edinbourg

Ça, c'est vraiment une fausse information qui a aussi été donnée sur Korben.

Ce qu'il se passe, c'est que le Maintainer Summit bouge de Vancouver ou il se passait en même temps que LPC vers Edinbourg a des dates différentes, en même temps que OSS EU et ELCE.

Bien évidemment, on ne sait pas ou Linus a prévu de passer ses vacances mais ce n'est ni Vancouver ni Edinbourg.

Et ça ne choque personne qu'ils font de l'https mais que manifestement, ils ne vérifient pas les certificat puisqu'il a pu faire du man in the middle pour récupérer les données?

Donc non seulement, les données sont envoyées à oneplus mais en plus, tout le monde peut les collecter.

Pour "EFI Test Driver" et "Mellanox Platform", ça n'est pas du tout Ingo qui a proposé les patches c'est respectivement Ivan Hu (http://www.spinics.net/lists/linux-efi/msg08921.html) et Vadim Pasternak (https://lkml.org/lkml/2016/9/22/958)

Il reste un problème pour la distinctions des VM par couleur: en fait, un application peut très bien décider de créer une fenêtre avec une bordure de la couleur qu'elle veut. C'est mieux expliqué ici: https://lwn.net/Articles/704287/

Nous (Free Electrons) sommes content de constater que nos supports de formations et slides de conférence aient servis à l'écriture de ce livre blanc. Cependant, je tiens à indiquer que la licence retenue pour nos supports (Creative Commons Attribution-ShareAlike 3.0, CC-BY-SA 3.0) est incompatible avec la licence de ce livre.

Exemple: Figure 1 page 22 et slide 11 de Buildroot.pdf

J'espère que Smile et Pierre Ficheux sauront rapidement corriger ce petit problème.

En fait, remword fait aussi la correction mais c'est au développeur de contacter le mainteneur. Les corrections ne sont juste pas les mêmes.

Pour ce genre de question, un site web:
http://cateee.net/lkddb/web-lkddb/EXT4_USE_FOR_EXT23.html

Entrée dans le noyau en 2.6.33 donc.

Le terme Yocto est souvent mal utilisé et ne doit pas être utilisé seul.

Yocto Project est une organisation qui s'occupe de la maintenance d'une multitude de projets open source.
Dire "j'utilise Yocto", c'est comme dire "j'utilise Airbus".

Parmi les projets, il y a notamment bitbake, OpenEmbedded et Poky et leur relation est la suivante:
- bitbake est un ordonnanceur de tâches, un peu comme Make mais avec son propre langage
- OpenEmbedded est le système de build, il utilise bitbake. C'est l'équivalent de buildroot (qui utilise Make)
- Poky est une distribution de référence, c'est à dire que c'est une configuration particulière des paquets qui permet de générer une distribution. Poky n'a pas vocation à être utilisée telle quelle et ne devrait jamais se retrouver dans un produit final. C'est une distribution qui permet de réaliser les tests d'intégration et qui de fait active un maximum de fonctionnalités ce qui ne convient pas pour un système embarqué.

La confusion la plus courante est donc d'utiliser Yocto à la place de Poky.

Donc on est bien d'accord, il y a une association 1:1 entre fix et correctif et patch et modification.

Traduire patch par correctif, c'est ajouter de l'information par rapport au texte original.

Je ne pense pas que ça soit une bonne pratique de se baser sur les recommandations du Canada. J'y ai fini mes études et j'avais le droit a tout mes anglicismes entourés en rouge avec écrit loi 101 à côté. Tout ça pour des mots simples comme buffer (de buffer circulaire, qui me semble être communément accepté en français) ou socket.

D'un autre côté, à l'oral, il font exactement l'inverse et parlent de fuse (fusibles), breaker (disjoncteur) ou wiper (essuie glace).

Aussi, je ne connais personne qui suit à la lettre la DGLFLF et je pense qu'il faut accepter que les secteur est mené par des anglophones.

Avec la DGLFLF, on peut faire des phrases qui ont du sens mais qui sont incompréhensibles:
"J'ai utilisé mon bloc-notes électronique pour écrire un correctif pour la barrière de sécurité du noyau. Le code ne passait pas le bon chiffre binaire dans le tampon configurant le connecteur logiciel."

Glossaire pour rigoler:
- socket: connecteur logiciel
- e-mail: courrier électronique
- URL/URI: adresse universelle
- boot: amorce
- applet: appliquette
- notepad: ardoise électronique
- notebook: bloc-notes électronique
- spammer: arroseur
- firewall: barrière de sécurité
- bug: bogue
- set top box: boîtier adaptateur
- chat: causette
- bit: chiffre binaire
- bytecode: code à octets

Je reviens aussi sur la première expression qui m'a fait tiquer, lors d'une des premières dépêches: "systèmes monopuce" (c'est encore plus drôle quand on voit l'utilisation directe de die dans la suite de la dépêche). Je ne connais pas un seul fabricant de SoC qui utilise "systèmes monopuce" pour décrire leur produit (même pas les fabricants Français).

Après, j'apprécie globalement ces dépêches, je reviens à mon point premier qui est qu'elles deviennent illisible sans dictionnaire tellement les expressions utilisées ne sont pas usitées. Je pense que quelqu'un que ne sais pas ce qu'est une GPIO par exemple ne saura pas non plus ce que sont des "entrées‐sorties à usage général". Je suis d'accord qu'il faille simplifier pour rendre les explications accessible au profane mais je ne pense pas que la traduction des termes techniques les rendent plus compréhensibles (en tout cas, c'est l'inverse pour moi).

Non parce que le correctif, c'est un fix. Donc la modification (patch) peut être un correctif (fix). Et voilà, les deux langues ont le même niveau de subtilité.

Moi je trouve dommage que la dépêche soit francisée à outrance ce qui en vient jusqu'à nuire à la lisibilité. Je donnerai pour exemple l'utilisation du mot "correctif" pour désigner un patch alors que c'est un ajout de fonctionnalité qui ne corrige rien.

Ou encore, je défie quiconque de me dire ce qu'est réellement: "Le nouveau système d’« accaparement » du système d’entrées‐sorties à usage général GPIO peut être utilisé pour câbler facilement — et de façon permanente — l’état d’une ligne GPIO spécifique sans nécessiter de pilote."

Il y a aussi les expressions bien traduites une fois sur deux:
- "Le MSM8916 intègre un ARM Cortex A53 quad-cœurs"
- "un processeur quatre cœurs ARM Cortex-A53"

On est bien en présence de quatre cœurs ARM Cortex-A53 dans les deux cas.