Pinaraf a écrit 3682 commentaires

Ben… oui… les jeunes que je croise au quotidien (une vingtaine d'années) n'utilisent pas le mail, donc le principe d'une ML et son usage leur sont complètement étrangers.

Donc, plutôt que de leur faire apprendre un outil indispensable plus tard (que je sache, il n'y a pas de discourse.gouv.fr, ni dans la plupart des entreprises), on abandonne ?

la barrière technique pour les nouveaux utilisateurs était trop élevée.

Vraiment ?
Il y a vraiment des personnes qui trouvent compliqué de s'inscrire et répondre sur une mailing list ? Et il est préférable, plutôt que de chercher à résoudre ce qui semble être un problème d'utilisabilité du mail, d'abandonner cet outil pour passer à des machins web ?
Y a-t-il des témoignages d'utilisateurs expliquant où se trouvent les difficultés ? Il ne suffit pas de dire «la barrière est élevée» pour que ce soit vrai, encore faut-il que ce soit démontré…

pour tourner sur un Pi sans serveur graphique par exemple.

Un pi sans serveur graphique ne veut pas dire sans GUI. Par exemple eglfs marche très bien…

L'autre bonne raison (dont je n'ai pas parlé, j'aurais dû) de ne pas vouloir tout faire en Qt, mais le cantonner vraimement à l'UI, c'est qu'un utilisateur pourrait avoir envie de lancer le soft en mode headless, pour juste lire son patch sur une machine pas forcément très performante, sans s'encombrer du poids de l'interface. Pour une session live par exemple. Du coup l'approche synthèse en C au plus bas niveau possible semble plus pertinente. Après je ne sais pas trop ce qui est possible de faire en pur Qt à ce niveau. Faut que je me renseigne serieusement.

Ça dépend, est-ce un problème que les libQtGui.so et autres soient installés ? Si c'est pas un problème, tu peux faire tourner une appli Qt sans lancer les composants d'interface graphique (voire avoir la flemme et utiliser un petit QT_QPA_PLATFORM=offscreen pour ne pas dépendre de X11/Wayland/eglfs)

Je lis «thread» et «Python» dans la même phrase, je m'inquiète.
Que vont faire les threads en question ?
Il ne faut jamais perdre de vue qu'en Python, il n'y a qu'un seul thread qui exécute du code Python par interpréteur. C'est le fameux GIL.
Mais donc, si on est sur des threads qui ne feront pas de tâche intensive en CPU… quel devient leur intérêt par rapport à un modèle plus événementiel ? Et si c'est des tâches intensives en CPU, alors ça part dans du multi-processus Python…

Mon avis, c'est que sa réponse améliore la blague…

Les avis, c'est comme les trous du cul : chacun le sien.

Non, les avis sont à partager pour éclairer chacun.

Je te laisse donc imaginer l'éclairage…

Tu crois que toutes les distros envoient un mail au développeur de chaque bout de code, librairie, petit utilitaire avant de fournir un paquet? Tu crois que c'est une méthode de fonctionnement valable? Moi je serais le dev de la lib trucumuche, ça me gaverait de recevoir 50 emails de ce genre.

Bonjour sophisme.
Comparer une lib ou un petit utilitaire à un chantier de reverse engineering produisant un ensemble de patchs au noyau, y compris un nouveau pilote DRM en Rust, et une autre pelletée de code dans Mesa et ailleurs…

Là, ce que fait la distro, c'est juste tenter de tirer la couverture à soi tout en prenant le risque de discréditer le travail des développeurs en mettant dans les mains de personnes pas du tout prêtes du code complètement expérimental.
Donc non, le problème ne sera pas seulement entre manjaro et ses utilisateurs.

La critique serait qu'ils utilisent un noyau instable dans leur version dite stable, c'est ça ?

La critique, c'est qu'ils utilisent un noyau hautement expérimental, dont le développement est incessant, et envoient ça aux utilisateurs sans avoir demandé aux développeurs de la série de patchs du noyau ce qu'ils en pensaient ou l'état général de la chose. En l'occurence, les patchs pour les SoC Apple M1 et M2. C'est ultra expérimental, j'ai cru lire que ça pouvait détruire les hauts-parleurs selon les réglages… on est bien bien bien au delà de "instable".
Du coup les développeurs des patchs ne sont pas contents parce qu'on ne leur a pas demandé leur avis, aucun canal n'a été mis en place.
Une distribution ne devrait pas venir prendre du code en développement (surtout à ce niveau là) sans discuter, c'est la moindre des politesses.

Sous le post ci-dessus plusieurs personnes se plaignent de la version Pinephone de la distribution et maintenant cette critique de l'équipe ARM.
Vous avez un avis éclairé sur cette distribution et l'objectif de l'équipe ?

Les avis, c'est comme les trous du cul : chacun le sien.

Mais sur mon pinephone, j'ai eu plusieurs problèmes directement liés à des choix côté manjaro. Le plus récent date de ce matin : contraintes incorrectes sur les versions des paquets, du coup mon système a cessé de fonctionner suite à une désynchro partielle des miroirs (le miroir FR/EU n'avait pas la bonne version de qt5-wayland-client).
Dans le lot des soucis liés à la distrib, le principal autre a été des fichiers de conf incorrects pour l'audio (alors que les confs correctes tournaient depuis des mois). Ça donne vraiment pas l'impression d'une distribution sérieuse, j'envisage de changer (mais y'a un port de Sculpt OS qui a été annoncé, ça m'intéresse bien donc j'hésite)

Avant de bannir un processeur, peut-être peut-on le faire tourner plus longtemps en idle (voire l'éteindre hein, on sait jamais)… Genre je ne pense pas que le site de lemonde doive consommer 2% de CPU en consultation… Du coup j'utilise noscript et ublock

C'est un modèle de plus en plus fréquent : un cœur libre, et des versions «étendues» (créer une base, quand même…) propriétaires payantes.
Pour ma part, c'est simple : je fuis. No pasaran. Hors de question.
Car il est alors impossible de contribuer au projet. Ben oui, tout dépend de la roadmap et des choix entre la version «open» et la version propriétaire. Impossible de savoir ce qui demain sera encore dans la version libre et ce qui sera dans la propriétaire.

Je sais très bien qu'il est très difficile de trouver un modèle commercial sans passer par ce genre de solution. Mais pour ma part je n'accepte pas ce compromis là pour ma production. Après tout, des projets comme PostgreSQL n'ont jamais eu besoin d'un tel modèle pour vivre…

Dans le cas présent, même pas. Si une appli lit la table des symboles elle-même, il faut patcher le code.

Sur debian, tu peux gérer ça comme ça :

echo "grub-efi-amd64 grub2/force_efi_extra_removable boolean true" | sudo debconf-set-selections

Oui, certains été buggués, notamment celui de la CM mano842, mais ce n'était clairement pas des bugs d'UEFI (quand même pas la faute a UEFI si les types sont infoutus de faire une interface non-mensongère!).

On pourrait avoir un long, long, très long débat sur ce sujet. «Doit-on imputer aux implémentations les conséquences d'une spécification trop complexe ?» vous avez 2H…

De mémoire, sur les trois couches de l'EFI, c'est la DXE qui fait la taille d'un noyau Linux (hors drivers, surtout quand on voit la taille des pilotes DRM), et quand on voit ce qu'elle doit implémenter de toute façon, c'est compréhensible.

Rappel sur les trois couches : en anglais, https://trmm.net/LinuxBoot_34c3/, sinon en résumé franchouillard d'un journal précédent

On a en fait trois couches dans EFI. Au cœur, se trouve le PEI, Pre‐EFI Initialization. Responsable de l’initialisation très bas niveau, comme le contrôleur mémoire (truc super‐tordu mine de rien, cf. les présentations des auteurs de coreboot), il gère à la fois le tout début de l’allumage de la machine, mais aussi la sortie de veille. Une fois qu’il a fait son travail, il laisse la main à la deuxième couche et disparaît.
La deuxième couche se nomme DXE, Driver eXecution Environment. C’est ce que l’on voit finalement du firmware. C’est un élément indépendant du matériel, capable de charger des pilotes et fournissant des interfaces génériques et normalisées aux applications souhaitant l’utiliser.
Enfin, la troisième couche, les applications EFI, en majeure partie les bootloaders donc… Alors, si vous trouvez que ça ressemble à BIOS + OS + applications, difficile d’argumenter tellement ça semble exact ! Au passage, a priori, une application EFI dépend de l’architecture : elle sera x86, x86-64, ia64.

D'ailleurs pour rechercher des infos pour ce commentaire, je suis retombé sur ce qui est sûrement le meilleur bug d'UEFI qui ait existé : https://mjg59.dreamwidth.org/20187.html

Moi, j'aime bien UEFI.

En vrac, ce que j'ai déjà eu comme horreurs sur de l'UEFI :
- UEFI 32 bits vs OS 64 bits. Une purge qui n'a pas été supportée avant un certain temps par Linux
- Implémentations complètement à la ramasse. Un BIOS buggué ça existait évidemment, mais avec un volume de code supérieur au noyau Linux, l'UEFI a nécessairement beaucoup plus de bugs possibles, et avec les mises à jour par les fabricants on est bien partis.
- La non conservation des variables à la mise à jour, en particulier des entrées de boot. À nouveau, ça dépend de l'implémentation (sur des Lenovo c'est les entrées de boot, sur mon PC perso c'est les flags du CPU comme l'activation de SVM), mais j'ai vu ça sur plus d'une machine, et donc si le grub n'est pas installé en «removable» (ce qui n'est pas par défaut sur Debian), tu l'as dans l'os. Si tu veux avoir plusieurs OS et choisir au boot d'ailleurs, tu l'as dans l'os aussi.

Quand on n'a jamais vu la lumière des autres firmwares, je peux comprendre l'attrait d'UEFI :) Mais si je pouvais avoir du OpenFirmware avec un Petitboot sur mon PC je ferais la transition immédiatement. (J'ai une machine ARM64/Petitboot à la maison, je suis ravi qu'ils aient fait ce choix plutôt qu'UEFI)

La signature des noyaux et boot loaders? C'est une fonctionnalité dont je n'ai pas besoin perso. L'utilisateur final ici en a-t-il réellement besoin, d'ailleurs?
Si Windows le requiert, alors ça serait bien la leur seul tort pour le coup (et c'est discutable en plus).

Windows 11 le requiert, Windows 10 le suggère cordialement.
Au passage, dans les pré-requis de Microsoft pour le matériel «Windows certified» depuis Windows 8 :
- UEFI x86/amd64 : Secure Boot doit être désactivable,
- UEFI arm : Secure Boot non désactivable.

une table de partition GPT (ou MBR, c'est possible aussi) : faute d'avoir créé une partition système EFI et d'y avoir placé un /efi/boot/bootx64.efi, il n'y a rien à démarrer.

Je n'ai jamais vu de carte mère qui contrôle le type de partition sur une clé USB. À chaque fois ce fichier sur une partition FAT a été pris immédiatement.

C'est hélas pas parce que tu as la liste des variables que tu sais laquelle doit être écrasée pour retirer l'association entre la machine et son ancien propriétaire… Elles n'ont pas de nom évident en tout cas, et un strings sur les valeurs n'a rien donné pour le moment.

pour la création de compte, il suffit de ne pas brancher la machine au réseau

La machine se considère encore comme appartenant à l'entreprise. Donc là c'est juste pas une option, une machine reconditionnée n'est pas supposée vouloir rejoindre le domaine de son ancienne entreprise.

Pour l'instant, le seul vrai bénéfice pratique est de permettre aux distributions de fournir un paquet contenant un driver pré-compilé (ce qu'interdit la licence propriétaire de Nvidia) et signé, évitant d'avoir à enregistrer une clé de signature dans le firmware de la machine en cas d'utilisation de Secure Boot.

C'est le bénéfice pour les libristes ça. Par contre pour nVidia il y a déjà un bénéfice : pouvoir dire aux vendeurs de Cloud (Microsoft, Google, Amazon) "regardez, vous pouvez utiliser nos GPUs dans vos offres et avoir le plein contrôle sur le pilote, plus besoin d'aller voir la concurrence". À titre d'exemple : https://www.phoronix.com/scan.php?page=news_item&px=Microsoft-AMDGPU-Hotplug

Dans un premier temps, ils veulent figer l'ABI pour pouvoir un driver userspace indépendant du kernel (et une facilité d'utilisation pour nouveau). Ensuite, il y aura un travail d'intégration dans le kernel Linux.

Note : ils n'ont pas trop le choix si ils veulent être intégrés au noyau. Les mainteneurs sont de plus en plus frileux à l'idée d'avoir un pilote impossible à tester, et donc maintenir, car dépendant d'éléments propriétaires en espace utilisateur.
Donc si nVidia veut intégrer son pilote au noyau, il leur faut un espace utilisateur, même incomplet (par exemple avec Vulkan uniquement), qui servira de référence. Rien ne leur interdira de faire comme AMD et d'avoir un espace utilisateur premium propriétaire.

Et pour le moment c'est testé que pour les usages datacenter, donc pas la partie affichage mais vraiment la partie G*PU* (CUDA/OpenCL).

Une autre qui mérite aussi je pense un coup de pouce :
https://participationcitoyenne.ccomptes.fr/processes/consultation-cdc/f/5/proposals/158

J'ai vu trop de connards confrères utiliser, voire se vanter d'utiliser cette astuce qui permet de piller légalement des allocations chômage.

Et pourquoi ce n'est pas banque qui me le dit ?

Tu serais rassuré de savoir que 3DS dépend de serveurs aux US (je sais plus pour quel service de 3DS) ?
Tu serais rassuré de savoir que les banques françaises se déconnectent de swift au fur et à mesure pour plutôt mutualiser/centraliser l'accès chez un nombre de guichets swift limité ?

La confiance, ça se mérite.

Aie confiance, crois en eux :)

wlp-acs, en non-abrégé World Line Payment - Access Control Server, est le service de contrôle d'accès fourni par Atos et utilisé par (toutes ?) les banques françaises pour l'implémentation, côté banque, d'ACS.
Cette page n'est absolument pas liée au site marchand. Par contre, de là à l'admettre comme étant une page de sa banque sur laquelle on peut sereinement saisir son code… non, faut pas déconner.

Sinon systempay est un PSP comme il en existe tant, un prestataire de services de paiement, qui donne une API simple pour éviter à tous les commerçants d'avoir à être certifié PCI-DSS et d'avoir à implémenter une horreur type CB2A.