Stéphane Bortzmeyer a écrit 645 commentaires

pour la référence je te renvoie vers le RGPD

Je veux bien le numéro de l'article qui dit ça. Car le RGPD, dans son article 3, dit exactement le contraire : il s'applique à toutes les données des résidents européens, quel que soit l'emplacement des données.

Il fallait vraiment avoir du fric ! Ces serveurs physiques étaient chers et on ne pouvait pas se permettre de les dédier à un usage intermittent.

à une époque pas si lointaine que ça, dans le monde professionnel on retrouvait des serveurs physiques dédiés, par exemple un serveur pour gérer les mails, un autre pour le serveur web et un dernier comme serveur de fichiers

Alors, je parle d'expérience (mon âge, etc) et ce n'était pas comme cela qu'on faisait : on mettait plusieurs services sur la même machine (ce qui ferait hurler les RSSI d'aujourd'hui mais Unix était précisément conçu pour cela). Cela répond à l'argument « utilisation optimale de chacune des machines ».

Il faut savoir que les données gérées par un datacenter sont soumises à la réglementation propre au pays où il est installé.

Comme on dit sur Wikipédia : « référence nécessaire ». En résumé : c'est faux.

Les autorités aux États-Unis, au nom du Patriot Act peuvent donc ainsi accéder aux données stockées sur leur territoire.

C'est un contre-sens : le Patriot Act (et autres textes étatsuniens) donne au contraire aux autorités étatstunienns le pouvoir d'accéder aux données qui ne sont pas sur leur territoire. (Sinon, cela n'aurait rien d'extraordiniare.)

Le problème serait que la vérification DNS avec Let's Encrypt nécessite une mise à jour dynamique puisqu'il faut insérer le défi envoyé par Let's Encrypt dans sa zone.

Comme impots.gouv.fr ou comme cam.ac.uk ?

« Ainsi, des enregistrements tels que LOC, RP ou HINFO pourraient voir le jour. DNSSec pourrait être de la partie également »

RP est abandonné depuis longtemps, HINFO aussi, LOC n'a jamais été très utilisé. Il serait plus utile de déployer les types modernes comme SVCB/HTTPS. (Ou WALLET, si on veut troller.)

Quant à DNSSEC, bien sûr qu'il est indispensable. En 2024, l'Internet est une jungle, donc la sécurité est une bonne idée.

« ou noms de SOUS-domaines si vous préférez » Pas besoin de préciser, tout domaine est un sous-domaine d'un autre (sauf la racine, qui est un cas particulier).

Correction d’un crash à cause d’une information de copyright mal enregistrée

Encore la faute des ayant-droits !

Le bouquin parle de l'infrastructure, pas des utilisations. L'IA a peu de conséquence sur l'infrastructure du réseau (bon, ça fait du trafic, mais la vidéo aussi).

Ça existe depuis longtemps (norme W3C « P3P »).

Je suis choqué de lire des choses pareilles sur LinuxFR. Par exemple que « Ces bannières, imposées par la Directive ePrivacy 2002/58 », alors qu'elles sont imposées par les auteurs de sites Web, qui récoltent des données personnelles sans bonne raison. Un bon site Web n'a pas de bandeau cookies tout simplement parce qu'il ne récolte pas de données personnelles.

Encore plus scandaleux, lire « l’impact réel sur la confidentialité des utilisateurs est limité, car la majorité des bannières servent principalement à des fins d’analyse web, de gestion de la publicité ou de suivi du trafic ». Parce que la publicité ciblée ne récolte pas de données personnelles, peut-être ? Et l'argument du suivi du trafic est un élément de langage classique des pubards et marketeux : suivre le trafic n'impose pas de suivre chaque utilisateur et on peut donc avoir un suivi de trafic sans bandeaux cookies.

Enfin, «  les utilisateurs acceptent souvent sans réflexion, sapant totalement l’objectif initial de protection de la vie privée », ne signifie pas qu'il faut arrêter les bandeaux cookies mais plutôt qu'il faut coller des amendes colossales aux sites Web qui ne marchent pas correctement si on a refusé les cookies. (Personnellement, je refuse systématiquement et, si le site ne marche pas, je vais voir ailleurs, le Web est grand.)

Bref, je tente de rester calme mais cet article est vraiment mauvais. On se croirait sur Presse-Citron et pas sur LinuxFr.

Quelles sont les spécificités du secteur public qui nécessitent un système d'exploitation spécifique ? Le secteur public utilise actuellement le même Windows que tout le monde, qu'est-ce qui empêche d'utiliser le même Ubuntu que tout le monde ?

Pour certains cas d'usage (indexation, recherche), ce n'est pas nécessaire.

Il n'y a pas de drapeau pour les régions, uniquement pour les pays (plus précisement, uniquement pour les entités qui ont un code ISO 3166). Les Bretons devraient arrêter de se regarder le nombril, la question n'est pas spécifique à la Bretagne.
Au passage, cette règle d'utiliser le code ISO 3166 est également une question technique : les drapeaux nationaux sont encodés en utilisant les codes en question comme point de code (le drapeau n'est pas un seul point de code mais une combinaison).

Je suis surtout heureux qu'on puisse enfin compiler du Fortran sur Haiku !

Blague à part, je plussoie aussi, bravo pour le travail et pour la dépêche détaillée.

Le blocage a pris fin le 31 août.

Il est probable que la décision avait été prise par l'hébergeur et/ou le transitaire et que la Cour n'était même pas au courant.

C'était pareil depuis la Guadeloupe ou la Nouvelle-Calédonie.

Il y a plein de sites Web / télés qui limitent selon le pays supposé de l'adresse IP. Ce qui est relativement rare ici (mais logique, vu le but de limiter les attaques par déni de service) est que c'est fait dans la couche 3, pas dans la 7.

HTTP/3 (passer de TCP à UDP)

Ce n'est pas la bonne description. HTTP/3 utilise QUIC et non pas UDP comme protocole de transport. QUIC ne peut pas tourner directement sur IP en raison de toutes les boxes àlakon qui bloquent les protocoles de transport inconnus, donc il utilise UDP mais ce n'est qu'un hack, fondamentalement, le protocole de transport de HTTP/3 est QUIC, pas UDP.

Sur ce service, rappelons aussi cette excellente BD.

Il y a toujours du nouveau. Désormais, l'ISO a sorti une norme sur l'étiquetage des dialectes (ou variantes si on trouve le terme dialectes pas assez politiquement correct), ISO 21636. https://www.iso.org/standard/84965.html

Je ne l'ai pas lue (comme toutes les normes ISO, elle est payante et pas redistribuable) mais si quelqu'un de courageux l'a fait et peut résumer…

Les étiquettes de langue IETF permettaient déjà d'étiqueter les dialectes et plusieurs avaient été enregistrés.

Il est clair que différents groupes n'ont pas le même cahier des charges. Les linguistes peuvent apprécier la rapidité d'enregistrement d'une langue, dès que l'article est publié, mais les bibliothécaires et documentalistes préfèrent davantage de conservatisme car une fois enregistrée, une langue ne pourra plus être supprimée, même si la science montre qu'en fait c'était une erreur.
Sans compter le débat entre fusionnistes (ISO 639-2) et séparatistes (ISO 639-3), qui regroupe en partie (mais en partie seulement) la distinction documentalistes / linguistes.

La gestion de la norme est faite par l'IETF. En pratique, la liste de diffusion ietf-languages. Les subtags de langue collent à ceux d'ISO 639 donc suivent son rythme. Les subtags de variantes sont gérés localement et suscitent parfois des discussions animées, comme on les aime à l'IETF (récemment, les variantes du Ladin).