nud a écrit 896 commentaires

Après on pourra aussi ajouter le nick IRC sur son serveur préféré, puis le serveur pixelfed, le compte github/gitlab/codeberg/sourcehut, etc. sans oublier que la ligne "posté par" est déjà immense.

Je pense (l'idée a déjà été proposée dans d'autres entrées de suivi) qu'il vaudrait mieux supprimer le site web, mastodon et xmpp et remplacer le tout par une liste de liens arbitraires (sous la forme "libellé: lien") comme ce qui est fait sur Mastodon, comme ça les gens peuvent mettre ce qu'ils veulent sans avoir besoin d'un liste de champs à rallonge. Puis on affiche ces liens dans un popover ou sur une page de profil et comme ça on résoud le problème de la ligne "posté par" à rallonge.

Manque plus qu'à trouver des développeurs/euses :-)

Sinon en attendant il est toujours possible d'ajouter des liens arbitraires dans la signature il me semble.

Surtout qu'il y a une proportion assez importante (j'ai pas mesuré) de liens dans lesquels la personne qui a posté le lien met une description en premier commentaire. Ce premier commentaire pourrait être… un journal.

Aucune, il fait ça pour le fun.

C'est fort probable mais pour que le tribunal statue il faut une plainte.

C'est la théorie, mais la pratique c'est que tant qu'il n'y a pas de plainte et de jugement qui explicite que le "consentement" recueilli n'est pas valable tout le monde s'en fiche. C'est ce que les ricains appellent le "court testing".

Et comme le péquin moyen n'a pas trop envie de se lancer dans une action en justice, il faut passer par des masochistes dans le genre de noyb ou La Quadrature du Net (y a-t-il un équivalent en Belgique? je n'en connais pas), auxquels je vous encourage à souscrire.

A défaut il est aussi possible de se plaindre auprès du service juridique d'un groupement de consommateurs généraliste (Test-Achats, 30 millions d'amis 60 millions de consommateurs, etc) qui ont les épaules suffisamment larges et qui pourraient réagir avec assez de signalement.

Oui y'a aussi la CNIL…

---

Fun fact, la théorie indique aussi que le tracking ne peut pas commencer tant qu'il a été accepté, or je doute que ce soit le cas en pratique ou quand on masque / ferme la petite boite. La théorie veut de toute façon que le consentement recueilli par beaucoup de ces petites boites à cookie remplies de dark patterns est invalide car obtenu par tromperie (layout qui change tout le temps, lien "refuser tout" gris clair sur fond blanc qui finit remplacé par un lien "accepter tout", etc.)

En pratique on sait bien que tout le monde s'en cognera tant que quelqu'un n'aura pas été condamné.

À noter quand même que vendre les données personnelles des gens et vendre un service permettant de relayer un courier à tout le monde, c'est légèrement différent. Dans le second cas la Poste exploite les données personnelles pour fournir un service mais ne les commercialise/diffuse pas.

J'ai un câblage structuré chez moi, quand je l'ai installé j'anticipais de l'utiliser pour faire passer un signal vidéo (à la place de mettre un coax) mais cet usage a entre-temps complètement disparu au profit de l'IP (les opérateurs eux-même n'utilisent plus de signal analogique).

Par contre j'utilise pas toutes les prises, mais ça a été pratique quand j'ai remplacé le wifi de ma box opérateur par deux access points openwrt, car j'avais plein de choix pour les placer sans devoir utiliser de mesh.

Je n'éprouve pas de fierté particulière à avoir un câblage structuré à la maison, j'ai eu l'opportunité de le faire donc je l'ai fait, je trouve ça plutôt pratique et je ne vois pas vraiment en quoi le câble "dépérit".

Dans la mesure où tout le monde est d'accord sur le fait que le fromage râpé en sachet c'est nul et que râper son fromage c'est bien mieux, est-ce que quelqu'un a des conseils ou des suggestions par rapport à une râpe de qualité ?

Pour ma part je suis plutôt partisan des râpes à roulettes mais celle que j'ai acquise récemment ne me donne pas entière satisfaction. Il s'agit d'une râpe en inox (qui ressemble à celle-ci même si ce n'est pas la même marque) très (trop) fin, avec deux cerclages en plastique qui rendent inexploitables 3mm de part et d'autre, et un espace trop important entre la roulette et le tour qui laisse passer de gros morceaux de fromage non râpé…

La précédente était en plastique et fonctionnait beaucoup mieux mais est restée longtemps indisponible (apparemment maintenant y'en a). Par contre la manivelle en plastique est fragile et en dix ans les deux ont cassé.

Un petit supplément en fer.

Je pense qu'il n'y a pas de calcium dans les rognures d'ongle, car l'ongle est en kératine et pas en os, et la kératine ne contient pas de calcium (50% de carbone, 22% d'oxygène, 17% d'azote, 6% d'hydrogène et 5% de soufre d'après wikipedia).

Mais heureusement il y en a dans le comté.

Puis des ports USB-A y'en a souvent plein alors que les ports USB-C sont très limités. Je n'ai encore jamais vu de hub ou dock qui proposait par exemple 4 ports USB-C additionnels alors que virtuellement tous les hubs même étiquetés "USB-C" proposent 4 ports USB-A.

Je ne suis pas vraiment convaincu que la tendance soit dans la disparition de l'USB-A du côté des périphériques et si j'ai le choix entre un périphérique en USB-A ou le même en USB-C je vais probablement choisir l'USB-A parce que je ne suis pas en mesure de facilement utiliser plusieurs périphériques USB-C en même temps.

En fait les seuls trucs USB-C que je possède sont un dock et des trucs qui sont destinés à être utilisés avec un GSM. Le business end de tout le reste est encore en USB-A, même ce qui est récent.

Bref tu n'es pas un salarié en remote mais un sous-traitant sous contrat.

LinuxFR utilise les gems redcarpet et sanitize via html-pipeline-linuxfr.

En jetant un œil rapide dans ce projet je constate qu'on a un TableOfContentsFilter qui génère la table des matières, qui fait ceci:

          toc << "<a href=\"#toc-#{name}#{uniq}\">#{node.inner_html}</a>"

Je suppose que le patch le plus simple serait de supprimer le lien dans le inner_html à ce moment-là. On pourrait même peut-être utiliser ça, mais alors on supprime aussi les <em> et les <strong>:

          toc << "<a href=\"#toc-#{name}#{uniq}\">#{node.text_content}</a>"

Si on veut supprimer complètement les liens dans les titres, alors il y a deux possibilités:

• ajouter un nouveau filtre sanitize appliqué avant le filtre mentionné ci-dessus qui supprimerait silencieusement les liens dans les h* directemement
• créer un Renderer spécifique qui enlève le support pour les liens dans les titres

C'est à peu près pareil entre le Luxembourg et la Belgique, mais alors on est dans un contexte "frontalier" (hérité de l'avant-COVID et de l'avant-télétravail), pas "full remote" auquel cas l'adresse qui compte est l'adresse à laquelle on habite.

"oh non pas lui!"

Le comportement de markdown est probablement correct dans ce cas car la norme HTML n'autorise pas de liens imbriqués, donc il ferme le premier lien (celui de la toc) avant le lien inclus dans le titre.

Le problème vient du lien dans le titre, qui devrait être supprimé lors de la génération de la table des matières. Ou bien il faudrait tout simplement interdire les liens dans les en-têtes.

C'est pas tellement courant de pouvoir faire du remote depuis n'importe où. Il me semble qu'il faut que la société ait un siège dans le pays d'où on travaille ou bien travailler en tant qu'indépendant et envoyer des factures. Si quelqu'un a des informations plus fiables que des "il me semble" qu'il n'hésite pas à se manifester !

Je n'ai pas trouvé la liste des bureaux mais a priori ils ont d'autres jobs ouverts à Paris donc ils ont vraisemblablement un siège en France, mais la France ne fait pas partie des lieux renseignés pour cette offre. Pareil pour Zürich et Genève. Pas de chance pour les Belges ou les Canadiens.

Faut aussi habiter dans un pays "pas cher" visiblement.

Oui, à peu près, mais certaines de ces alternatives (par exemple Sepia) modifient plus que la valeur des couleurs.

Cette approche permet aussi de couvrir les besoins de "thèmes sombres". On pourrait même détecter la préférence de l'utilisateur pour afficher un thème sombre ou clair, c'est à la mode.

De même, le support des différents types de devices (le "responsive design") devrait faire partie de la stylesheet par défaut et pas un style séparé (ce qui n'était pas possible y'a 10 ans). Idem pour l'impression. Ces cas ne justifient plus la présence de styles alternatifs.

J'ai déjà proposé par le passé de supprimer tout ça quitte à laisser les gens utiliser une autre stylesheet hébergée ailleurs si ça les chante, mais une autre possibilité qui couvrerait une bonne partie des usages ce serait tout simplement de permettre d'avoir des nuances via des variables SASS ou CSS, genre on définit quelques couleurs et voilà. C'est comme ça que la plupart des sites "customisables" fonctionnent de nos jours et c'est relativement simple à maintenir tant qu'on ne permet que le changement de paramètres.

Evidemment dans un premier temps il est possible de supprimer tous les styles alternatifs en attendant que quelqu'un d'intéressé fournisse un patch.

Cool, la possibilité d'utiliser (accidentellement) le format de dates US sur un site entièrement en français, ça manquait!

Y'a plus qu'à traduire l'entièreté du site et avoir en.linuxfr.org et de.linuxfr.org !

Est-ce que ta machine est configurée avec ce format d'affichage ? Si oui, on pourrait laisser rails faire l'affichage selon ces préférences.

M'est avis que c'est plutôt du côté du navigateur que tu devrais gérer ça, alors, mais le problème c'est que si ton PC est en anglais ça portera encore plus à confusion.

En fait, si je cherche une autre solution, c'est parce que je trouve qu'écrire le mois et l'année en entier alourdi le texte écrit sous les titres des contenus

Au point où on en est je ne pense pas que ça change grand chose, ces sous-titres sont un accident de train de toute façon. Mais si vraiment ça t'embête il est aussi possible d'avoir les noms de mois courts en utilisant %b au lieu de %B. L'effet n'est pas vraiment remarquable en mars ou en juin mais peut-être plus en en septembre ou en décembre.

Je pense aussi que le format DD/MM/YY est confus parce que sur la machine que j'utilise maintenant certaines applications utilisent MM/DD/YY et d'autres DD/MM/YY et les deux sont chiants car nécessitent de faire plus attention. Avoir le nom du mois (éventuellement abrégé) résout cette ambiguïté à peu de frais. Mettre l'année en premier (façon RFC 3339) aussi mais les gens sont peut-être moins familiers avec ce format.

Par contre je ne regarde pas souvent les dates des commentaires donc ça ne m'a jamais gêné outre mesure.

Si le projet a commencé à utiliser le calendar versioning après 2000 c'est safe d'utiliser deux chiffres, au pire en 2100 si le projet existe encore ils pourront juste passer à trois chiffres sans que ça soit bizarre.