nud a écrit 830 commentaires

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.

Tu te dois maintenant de proposer une recette pour faire quelque chose des pois chiches.

Oui mais il a fini directement dans les spams.

Si on est agacé par son gamin qui dit "wesh" au lieu de "oui" plutôt que de l'utiliser à la place de "salut" comme il se doit, on est quoi?

Il y a une solution toute trouvée, c'est la raclette estivale.

Car oui en cette saison y'a peu de tomates dans le jardin.

Mon laptop pro précédent était à 99% de la limite après ~4 ans pour certaines cellules. Je n'ai aucune idée de ce que j'ai fait pour causer autant d'écritures mais apparemment on peut y arriver. Je pense que c'est lié au fait que le disque de 256G était plein à 90% la plupart du temps, ce qui fait que les cellules vides ont pris cher parce que le wear leveling ne pouvait pas fonctionner correctement dans ces conditions.

En d'autres termes, pour vivre longtemps un SSD ne doit pas être remplis à ras bord de données qui changent peu, il vaut mieux avoir un disque à moitié vide. J'ai d'ailleurs déjà vu des articles qui préconisaient de ne pas partitionner l'ensemble de l'espace disponible.

Alors je sais pas en France, mais on cultive du thé en Belgique.

Edit: Apparemment aussi en France

Il existe même dans le commerce des plants de "pomates" au nom évocateur de "Ketchup'n'Fries", comprendre un plant de tomates greffé sur un plant de pomme de terre, qui produit les deux.

Il faut remarquer ici que le changement de licence est un changement depuis la BUSL vers leur nouvelle FSL. Techniquement le projet Sentry était déjà sous une licence non-libre depuis 4 ans. Donc ça apparaît plus comme une marche arrière partielle vu que la nouvelle licence est prétendument plus modérée.

Par ailleurs à première vue ce changement ne concerne que l'application web et pas les autres projets (principalement les libs qu'on est censé mettre dans ses projets) qui a première vue sont toujours sous licence MIT ou Apache 2.0

alors qu'avant il pouvait utiliser

'manque un bout non?

Attention cependant que les serveurs mail classiques (postfix, dovecot) ne supportent pas l'OCSP stapling, et donc il faut bien veiller à ne pas activer must-staple sur le domaine qui gère les mails!

Ces release notes-ci me semblent plus accessibles: https://www.blender.org/download/releases/4-0/

Par contre il faut une machine de guerre pour afficher cette page.

Le télétravail a contribué à normaliser la demande implicite d’être joignable à tout moment par son chef, et en pratique le « droit à la déconnexion » est difficile à faire respecter.

Je ne comprends pas le lien entre les deux. Tu as des horaires de travail définis, tu dois être joignable pendant ces horaires et tu ne dois pas l'être en dehors de ces horaires (il me semble même que tu ne puisses pas légalement être contacté sauf force majeure hors de ces horaires). En quoi le fait d'être en télé-travail modifie ces principes ?

Comme je vois que tu utilises nginx pour ton site perso tu pourrais aussi utiliser des Server-Side Includes. C'est un peu démodé mais tu peux juste avoir un commentaire dans le HTML du type <!--# include file="header.html" --> et voilà, pas besoin de javascript du tout.

Mouais faut arrêter le complotisme à un moment. La plupart des choses dans la vie sont optionnelles mais obliger les fournisseurs à les supporter est à peu près la seule façon de s'assurer que ça "prenne". Tiens, par exemple, si le support de Linux n'est pas rendu obligatoire on parie qu'il sera inexistant ?

Par contre à quel moment comptes-tu (faire) rectifier ton journal et son titre ?

Je suppose que tu voulais dire "sans l'accord"?

Je ne vois pas vraiment la motivation pour un fork communautaire dans la mesure où AGPL est toujours une licence libre (au contraire de la BUSL qui est malheureusement populaire dans l'actualité récente).

Les gros utilisateurs de Matrix (par exemple GNOME) s'accommoderont très bien de l'AGPL. Le CLA est plus ennuyant mais on peut toujours maintenir sa pile de patch par dessus l'upstream, c'est moins "coûteux" que de maintenir un fork.

S'il y a d'autres utilisateurs corporate libre à eux de maintenir le fork sur base de la dernière version sous licence Apache 2.0.