Sytoka Modon a écrit 4546 commentaires

Mon soucis est que beaucoup de personne parle de dématérialisation… Je n'ai pas trouvé mieux à leur proposer que digitalisation. Et en général, elles acceptent.

Numérisation -> cela fait scan de document…

Si quelqu'un a un meilleur mot, je suis preneur

En général, j'utilise la commande file -i qui me donne le langage, le type de caractère de fin de ligne et l'encodage. À vrai dire, je ne sais pas sur quel algorithme elle se base…

La fonction publique ne peut pas donner facilement de l'argent à un projet libre. C'est globalement incompatible avec le principe des finances publiques. Ce principe peut sembler gênant vis à vis de la manière dont beaucoup de logiciels libres sont développés.

Pourquoi ce principe ? Il s'agit d'argent public donc du contribuable. L'argent public ne peut servir à faire une subvention cachée sans vote au conseil municipal par exemple. Tout cela est très encadré afin de ne pas faire de concurrence déloyale ou de filer de l'argent en douce à un petit copain…

Les subventions sont donc possibles mais elles sont votées et bien encadrés.

L'idéal est d'avoir une facture correspondant à un service ou à l'achat du développement d'une nouvelle fonctionnalité. L'intitulé doit être précis. Encore une fois, c'est normal, on parle d'argent publique donc appartenant à tous.

Ainsi, il est possible de participer légèrement à Debian via le projet LTS encadré par Freexian qui accepte les bons de commande. Pas mal de mairie passe par l'Adullact pour avoir des factures en bonne et due forme pour les logiciels libres.

Les règles de la comptabilité publique ont pour objectif de limiter les dérives du copinage. Si un expert en comptabilité avait des bonnes règles à proposer pour le cas particulier de la fonction publique, cela pourrait être intéressant.

Ou en est le projet Metafont associé à TeX ? Il a permis avant UNICODE d'écrire de magnifique document avec de mémoire une manière relativement simple de construire les polices.

Si on veut de la perf, on fait du Fortran. En Fortran, l'ABI est cassé à chaque version !

Grenoble Capitale des Alpes… Je l'ai vu plusieurs fois cet hiver !

Idem, dans le fichier de control, il faut mettre

Architecture: amd64

Il faudrait que vos paquets Debian finissent par _amd64.deb et non _all.deb car ce sont des binaires donc ils ne fonctionnent pas pour tous les CPU.

Question bête, ce serait facilement intégrable dans gCompris ? Car cela a l'air sympathique ces deux petites applications.

MQTT est un bus message sur lequel tu interconnectes un peu comme tu veux les flux et peut ainsi avoir des "triggers" maison. À coup de serpes, c'est un service XMPP ultra simplifié ! C'est standard et fonctionne dans l'embarqué sur un Arduino. La question serait plutôt de savoir pourquoi les outils de télémétrie n'utilise pas MQTT ?

J'allais dire pareil. Je ne vois pas ce qu'apport BIMI dans la sécurité et attacher un logo à tous les courriels ne fait qu'augmenter leur taille donc c'est très mauvais côté bilan carbone.

La signature numérique par contre, oui cela a un intérêt.

Vrai, mais faux !

Le code militaire par exemple n'est pas public… On trouve ainsi de nombreux cas particulier. On pourrait dire que par défaut, le code de l'état devrait être public, sauf demande pour qu'il ne le soit pas.

C'est peut-être le moment de faire une contribution à Grammalecte pour engager des personnes afin de lui rajouter des fonctionnalités ?

En plus, deb et rpm sont quasi aussi vieux et c'est pas pour cela que rpm a basculé sur deb… Et ils y a des défauts de jeunesse compliqué à changer.

Dans le calcul, on utilise plutôt Spark qui est plus adapté et au final, fonctionne mieux souvent que Nix ou Guix.

Bon, tout cela fait pas mal de diversité ;-)

Il est vraiment très simple de faire un paquet Debian de base, certes pas conforme 100% à la qualité Debian, mais qui marche. En gros, un tar avec les fichiers, un tar de contrôle et hop, les deux dans un ar. C'est tout. C'est bien plus simple qu'on ne le croit avant d'en faire un.

PS : évidement pour les cas simples, soit 99% des paquets. Si vous voulez du debconf avec paramétrages… C'est un peu plus complexe.

• IPv4 - Janvier 1980
• IPv6 - Décembre 1998

On est en … novembre 2021 !

La bascule de IPv4 vers IPv6 est un échec. Cela ne veut pas dire qu'elle ne finira pas par se faire, mais ce sera quand même un échec.

Pour reprendre ton exemple, il y a des sauts technologiques qui méritent une rupture. Il n'y a pas de saut technologique entre IPv4 et IPv6. Il y a des choix qui ont été fait qui ont fortement compliqué les choses sur les couches bases et qui ont au final, ralenti tout le processus. Sur un réseau local, ARP et DHCP fonctionnent très bien. Il n'y avait pas forcément besoin de tout changer.

Un bon exemple d’extension réussi. Les VLANs. Ceux-ci sont inexistants à l'origine. Zut, comment les rajouter ? Soluce, les VLAN ne passent pas les routeurs et on rajoute en amont du paquet IP un petit bout VLAN. Et hop, tous les commutateurs très rapidement ont eu des implémentations VLAN fonctionnelles.

C'est assez rare que les citoyens soient consultés sur ce genre de question…

Clair, juste 127.1. n'a aucun intérêt… On va pas changer tout internet juste pour cela !

On voit encore une fois l'erreur d'IPv6 de ne pas être rétrocompatible (et surtout d'avoir imposé trop de changement de protocole / manière de faire) !

Cela se fait. Par exemple les sociétés émettent des titres, puis les rachètent et en détruisent au grès de la conjonction. Donc il n'y a pas de raison que la BDE ne détruise pas des € de temps en temps si besoin.

Je ne connais pas grand monde qui fait fonctionner un cluster sous RHEL, c'est trop cher les licences.

Quand tu es le CERN est que tu achètes 20 racks d'un coup, le constructeur est près à faire quelques efforts ! Et comme je l'ai dis, depuis 20 ans, aucun soucis sous Debian. Quand au cycle de vie, avec la LTS / ELTS, il y a moyen d'avoir plus long. Et j'ai parlé de Debian ou dérivée donc cela aurait pu être Ubuntu.

Personnellement, j'ai toujours eu l'impression qu'ils mettaient beaucoup d'énergie à suivre RHEL et que celle-ci aurait pu être mieux utilisé… Et les noyaux sous Debian / RHEL… peuvent être les mêmes. À vrai dire, le code dérive des mêmes dépôts. Mais bon, tout cela est une impression personnelle.

CentOS ou Scientific Linux étaient basé sur RHEL qui ne fournissait pas les recettes de construction de la distribution, entraînant de fait la galère pour reconstruire une équivalent de la RHEL.

Avec Debian, toutes les recettes sont données, et c'est hyper facile de faire une distribution dérivée ou augmentée.

Je n'ai jamais compris pourquoi le CERN qui promeut le libre n'est jamais passé à Debian. Ce serait un super acteur de poids dans le monde pour la promotion de cette distribution collaborative. Une occasion manquée ;-)

(Cela fait plus de 20 ans que je suis passé de RH à Debian sur tout mon parc sans avoir jamais regretté la bascule).

Si le logiciel était conçu libre depuis le début, les gros défauts pourraient être vu rapidement, ou une autre boite pourraient reprendre le développement…

Il n'y a pas de réelle nécessité que le logiciel soit fermé dans 95% des cas. Le point critique est les données donc l'accès à cette base de donnée, pas réellement le logiciel.

Ok, je n'ai jamais essayé car je ne savais pas (ou j'avais oublié). Il est vrai que debian-installer manque de bras. Je rappelle que Debian est un projet collaboratif donc si personne ne se bouge, les choses ne se font pas.

À vrai dire, avec l'UEFI, je serais plutôt partant pour virer grub… Avec l'EFI sur les machines Itanium, on n'avait déjà plus d'amorceur. Est-il préférable d'avoir grub ou un boot direct sur /boot ?

La partition /boot est nécessaire en cas de chiffrement du disque système.