Pinaraf a écrit 3671 commentaires

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.

Alors qu'on peut déjà booter windows 10 sur un volume btrfs…
https://github.com/maharmstone/btrfs

Encore une réinvention de la roue…

Comme pour tous les projets, le choix du langage est une illusion.
On a toujours un ensemble de critères à prendre en compte, et souvent ces critères vont, hélas, exclure des solutions comme Ada.
À l'arrache, comme ça, je donnerais les critères suivants…

1) connaissance du langage vs volonté d'apprendre des nouvelles choses

Si un critère financier est présent, peut-on financer l'apprentissage d'un langage pas tous les participants ? Et compliquer de futurs recrutements ?

2) temps de développement intrinsèque au langage

Certains langages permettent tout de même de développer plus vite que d'autres. Les langages de script sont tout de même réputés pour la vitesse que l'on peut atteindre en développement, certains langages sont mieux outillés pour des cycles de développement rapides (l'édition en live du code du programme alors qu'il fonctionne peut permettre de faire une coquille vide puis itérer très vite)…

3) outillage

A-t-on des outils de développement corrects ? Coloration syntaxique, complétion de code, documentation navigable et claire…

4) disponibilité des bibliothèques

A-t-on le temps de réinventer toutes les roues dont on va avoir besoin ? Ou le temps de coder des bindings pour utiliser des bibliothèques d'autres langages de programmation ?

Sur le dernier projet que j'ai commencé, je voulais utiliser d'autres solutions techniques, d'autres frameworks ou langages. Je me suis finalement rabattu sur Python/Django, pour un critère simple, très personnel et temporaire : j'ai une épaule fraîchement opérée (coiffe des rotateurs), donc il me faut une solution où l'on écrive le code le plus concis possible vu que je n'ai qu'une seule main…

Quelle horreur, fermer son compte linuxfr ? Brrr…

Les militants dans les associations ne peuvent pas être partout, ils s'usent, ils ont une vie à côté des actions (y'a eu un post sur le sujet il y a quelques mois je crois).

Tout à fait, et j'ai déjà assez avec une émission de radio sur le libre, je ne peux pas en rajouter…

Sauf qu'ils font partie de ceux qui attaquent publiquement «Mon Espace Santé», en ignorant royalement l'éléphant au milieu de la pièce.
Mon Espace Santé qui, au passage, a d'autres buts que supprimer les services de secrétariat en enrichissant ses actionnaires.
En l'absence d'un tel service, comment je peux communiquer au personnel médical que je réagis mal au tramadol et à la morphine (deux antalgiques courants), que je souffre d'allergies pouvant impacter une hospitalisation, qu'une intubation risque de me déboîter la mâchoire… (et j'en ai d'autres, je n'invente rien, j'ai pas de bol…)
L'implémentation respecte le RGPD et est hébergée en France : c'est déjà mieux que ce que d'autres proposent. J'eus préféré une implémentation plus liée à la carte vitale. Que ma carte vitale soit obligatoire pour lire mes données par exemple. Mais on tombe sur des problèmes d'utilisabilité, surtout face aux solutions qui mystifient tout le monde avec des incantations magiques (doctolib affirme que vous seuls pouvez lire les documents envoyés par un médecin, ce qui est faux puisqu'il arrive en clair (dans du TLS) depuis leurs serveurs)

Puppet est un très mauvais outil pour déployer un truc par dessus de la merde fait à la main. Il est fait pour gérer ses machines comme des troupeaux, pas comme des animaux de compagnie.

Cas concrêt : j'ai un serveur sur lequel un disque flanche. Je profite de l'occasion pour ajouter une paire de disques, et en synchro avec mon fournisseur je fais l'intervention logicielle quand il fait la partie hard.
Dans puppet, il faut que je maintienne en continu ma liste de PV. Le VG est là et ne bouge pas, mais non, il exige de connaître les PVs, et va donc devenir une nuisance pour l'intervention, voire, en cas d'intervention d'urgence le 1er janvier à 4H du matin, un danger si on oublie de le désactiver…
J'aimerais lui dire «notre contrat à tous les deux : je te file une machine avec le VG machin». Mais il exige d'aller jusqu'au bout, savoir la constitution du VG. Et là c'est pas possible.

Il y a un peu plus d'un an, un collectif d’associations de patients et de syndicats de médecins contestait le partenariat noué entre Doctolib et le Ministère de la Santé devant le Conseil d’Etat.

LQDN n'y est pas.

Le juge des référés du Conseil d’État considère que les données en cause ne sont pas des données de santé.

Décision débile à souhait. À partir du moment où tu vas mettre nom, prénom et numéro de sécu, tu vas être lié à tous les futurs rendez-vous que tu prendras, voire les RDVs passés. Tu acceptes des CGV, une violation du RGPD (données chez amazon et utilisation de cloudflare, entreprise US, en l'absence d'accord licite de transfert de données c'est chaud à justifier)… puis pour beaucoup de gens, une fois le doigt pris dans l'engrenage, pourquoi s'emmerder, autant utiliser le service, et tant pis pour la concurrence.

elle l'a jamais fait

C'est qui le «elle», l'état ? L'abandon à doctolib, a minima dans ma région, est catastrophique : tous les centres de vaccination publics (y compris en CHR, ou les installations dans des gymnases, des salles des fêtes…) passent par là. Et au tout début les médecins ne pouvaient pas le vacciner eux-même.
Donc oui, un abandon total.

Médecins qui peuvent, sans ton accord, utiliser Doctolib pour leur gestion, et y saisir des infos te concernant…

Où était LQDN quand l'état a abandonné ses prérogatives de santé publique (et nos données) en confiant la vaccination covid à doctolib ?
Le problème c'est que quand l'état le fait c'est mal, mais le privé on s'en fout ?

Bref, n'avoir rien compris à l'affaire.
L'outil se dit simple parce-que n'imposant rien

J'oubliais de te remercier pour ton mépris.

Prenons une page de la doc :
https://docs.ansible.com/ansible/latest/collections/ansible/builtin/command_module.html

Quels paramètres sont indispensables pour qu'ansible respecte son principe de pouvoir lancer les playbooks à l'infini ? creates et removes. Ils sont optionnels, et guère mis en avant alors qu'ils méritent a minima une place dans le synopsis, voire un warning du type :

if creates is None and removes is None and register is None:
  logging.warn("tu fous quoi là ?")

Quand toute une boite utilise un outil, y'a deux options :
- croire que tout le monde apprendra à bien l'utiliser
- avoir un outil contraint

À $job-1, ansible était déjà là, mais l'option 1 n'a jamais été approuvée, «it works don't fix it» (grosso modo). Et ça semble être la norme plus que l'exception en entreprise, ce qui me fait envier l'option 2, la contrainte, ou l'option 1 avec des outils dont la courbe d'apprentissage est un mur dans la face.