Tout à fait, mais je n'ai pas voulu être probablement mauvaise langue en pointant la mauvaise volonté (sans preuve indiscutable …même s'il est vrai que je ne donne pas d'élément d'identification ici) Plus précisément, j'ai cru déceler avec les deux derniers avec qui je l'ai vécu plus une volonté de ne pas comprendre Git (et de ne pas apprendre de nouveaux contextes et façon de faire en général) que de la volonté d'emmerder (mais au final quand ça fout la grouille ça y ressemble un peu pour les anciens dont je faisais partie.) :-( Ces gens faisaient le minimum syndical…
Dans la même boîte, avec l'équipe d'avant, on a vu aussi des souci (d'où le fait que je me dis que Git n'est pas trivial si on n'est pas correctement pris en main, ce qui ne prend que dix à quinze minutes pour les commandes de bases appliquées à un dépôt existant) mais la personne s'est vite rendu compte que ça n'allait pas et a demandé de l'aide aux collègues …et aujourd'hui dans une autre boîte le même sys-admin git les doigts dans le nez :-D
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
la syntaxe semble tellement tomber sous le sens (c'est quasi la même que Creole qui a produit une documentation abondante sur les raisons de tel ou tel autre choix)…
Exactement, la raison pour laquelle je dis que la syntaxe Wiki est mieux fichue (en plus d'être plus riche de base) que Markdown ! Malheureusement, il y a beaucoup de dialectes qui ont l'avantage d'être plus riche que Creole (mais n'est-ce pas le même souci avec toutes les « saveurs » de l'autre qui font que je ne peux pas juste prendre mes écrits pour Github ou Gitlab et les mettre sur Linuxfr juste pour prendre cet exemple.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
La transition sera d'autant plus longue que la très grande majorité des utilisateurs n'ont pas vu de problème quand on leur a rapporté les multiples scandales de boites qui marchent allègrement sur les lois et se foutent totalement de ce qu'on fait de leurs données ou de la façon dont on va les manipuler avec des algos pas faits pour leur bien-être.
Je doute très fortement que le coup des URLs changera quoi que ce soit.
Je doute aussi que le coup des URLs parle à grand monde, mais on propos est que à chaque égratignure on a une excuse de plus pour se barrer… Et il faudrait lire la longue liste des chefs d'accusations aux aveugles au lieu de les encourager à la complaisance ou de se dédouaner de nourrir le système à base de « pas le choix, on a trop d'infos vitales dessus blah blah » Comme expliqué dans un autre commentaire, d'autres ont fait le saut et la mort sociale dont on les menacé en cas de sortie de la secte/matrice n'a pas eu lieu.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
En plusieurs années d'admin systèmes je n'ai grosso modo que utilisé les commandes git suivantes: add, commit, pull, push, restore et parfois revert.
Pour être dans le métier (enfin jusqu'à il y a peu), je vois (ou plutôt, maintenant, j'ai vu) beaucoup d'admins pour qui c'est compliqué : pas de pull avant de modifier leur local poussiéreux puis, éventuellement de push et écraser tout ce qui a été fait entre temps, quand ils prennent le temps de bien faire, c'est panique à bord parce-qu'ils ont modifié avant de récupérer le distant et qu'il y a un conflit qu'ils savent pas résoudre, etc.
Est-ce que par hasard, cela ne serait pas dû à une mauvaise expérience
La mauvaise expérience c'est presque sûr. Je trouve honnête de ne pas forcer et d'admettre qu'on n'a pas compris que de jouer avec les données et foutre n'importe quoi (par contre dommage de servir cela avec de mauvaises excuses mais peut-être que l'absence du bon diagnostique peut expliquer la chose.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Comme mentionné dans d'autres commentaires il faut des bibliothèques dédiées, qui ne sont pas si simples malgré cela. et évitent les mois dans la mesure du possible.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Sauf que ça veut dire que l'équivalent du mois de juin tombe de temps en temps en hiver,
Si tu avais pris la peine de regarder tu verrais que ton juin ne tombe jamais en hiver,
Je reformule : dans lequel de mes liens as-tu lu que juin tombe de temps en temps en hiver ? Les trois exemples que j'ai pris sont calés sur 365 jours et commencent le premier janvier : les saisons théoriques tombent encore dans les mêmes périodes, ou alors il y a un passage dont j'ai eu une mauvaise compréhension ?
Les difficultés liées aux irrégularités des mots ont souvent été évoquées ici, et ce n'est pas pour rien que la gestion des certains calculs de dates fait une grosse partie du code qui n'est pas exempt de bogues. Tout con par exemple, comment tu ajoutes deux mois à n'importe quelle date …sans devoir énumérer plein de cas particuliers ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
L'article conclue par « Users could avoid Facebook, but that may not be possible all the time. » ; mais moi je dis dis juste que « Users should avoid Facebook, full stop. »
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Hier encore, influencé cette fois par le site toolinux.com, je songeais à nouveau à SPIP, qui a le grand mérite de s’attarder sur la typographie française et de privilégier la lisibilité et l’accessibilité. J’ai découvert plus avant l’implication et le travail de Romy, et qu’elle était à l’origine de Cuisine Libre en plus de TinyTypo, chapeau madame. Mais SPIP, en plus de reposer sur une base de données traditionnelle, s’appuie sur une interface d’administration obligatoire m’imposant mille fonctions (de travail collaboratif et de révisions, ou de publication avec sur-titres, sous-titres, chapeaux…) dont je n’ai pas du tout besoin, tout en ne proposant par ailleurs pas de base la possibilité d’organiser les publications autrement que de manière hiérarchique et non transversale. S’il y a bien une chose que j’apprécie dans Wordpress, c’est ses catégories et étiquettes, et leurs pages d’affichage fournies en standard. J’aimerais un outil qui laisse mettre en place ses propres taxonomies et des boucles liées sans devoir en passer par du code, et vu tout ce qui est développé, notamment Gutemberg chez Wordpress, c’est un souhait tout à fait raisonnable, mais je garde aussi ma liste au père noël pour une autre publication.
Tout d'abord, concernant la base de données, tu n'as besoin d'un SGBD supportant des connexions multiples si tu es seul/seule à écrire du contenu (cas d'un blog perso) et/ou s'il y a très peu de comptes et de publications (j'entends par là que vous n'êtes pas une dizaine à publier une foule d'articles toutes les heures ?) Ça tombe bien, SPIP supporte les moteurs PostgreSQL, MySQL/mariaDB, SQLite …ce dernier répond très bien à ta problématique : quand tu transfères ton site, le fichier de bdd l'est aussi et ce ne sont pas des opérations à côté et pas plus de ressources.
Ayant souvent du contenu structuré, j'ai toujours détesté son absence dans Wordpress ; et je vois beaucoup de site basés dessus qui sont obligés de faire des contournements du système de catégorisations ou d'installer des plugins. Comme tu n'as pas ce besoin, pas de souci : il te faut juste créer une rubrique racine fourre-tout que tu appelleras blog qui seule sera affichée par ton squelette. Si demain tu changes d'avis, ton site peut facilement évoluer (mais on ne va pas détailler cet aspect qui est loin de tes préoccupations.)
Il existe déjà des squelettes si tu n'as pas d'idée ou de temps pour t'en faire un sur mesure → https://contrib.spip.net/Squelettes-pour-blog
Les catégories et étiquettes existent de l'autre côté et s'appellent groupes de mots et mot-clés. Leurs pages d'affichage fonctionnent de la même façon avec la plupart des squelettes évoqués, mais tu es libre de faire à ta sauce sans sortir l'artillerie de dev PHP comme en face. D'ailleurs, faire des boucles liées et sur mesure est dans l'ADN de SPIP et il te suffit d'adapter ton squelette et d'utiliser les nombreux plugins disponibles pour te simplifier l'existence.
Pour les fonctionnalités qui seraient imposées, ce n'est pas du tout le cas. L'installation par défaut ne te demande que le titre et le texte de l'article. Mieux, tout juste après l'installation, à la première connexion, tu es invité/invitée à tout configurer à ton goût et tu verras que rien n'est imposé.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Parmi toutes les propositions possibles j'ai listé celles qui, solides, qui remplissent tes critères. Si tu avais pris la peine de regarder tu verrais que ton juin ne tombe jamais en hiver, mais bon c'est plus facile un raisonnement non basé sur les faits.
Passer de sept mois irréguliers à zéro mois irrégulier et un ou deux jours particuliers c'est sûr que ce n'est pas plus régulier. C'est une façon de voir les choses ; je ne pige pas mais pourquoi pas ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
→ https://qntm.org/calendar
Juste une liste d'excuses pour la résistance aux changements, avec un grand focus sur l'année solaire (365 jours, bissextiles, tout ça, voir mon autre commentaire…)
La vrai raison du rejet d'un calendrier plus cartésien en France s'appelle Napoléon (qui l'a aboli au 1er janvier 1806 : si ça ne tenait qu'à lui on aurait probablement eu le pied napoléonien au lieu du mètre…) Zut, on n'est plus vendredi sur aucun fuseau horaire.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Pour un calendrier régulier, je n'entends pas forcément l'abolition des années bissextiles mais d'avoir un système globalement plus régulier dans le comptage des semaines (la semaine de 5 jours est un exemple, 7 ne me pose pas de souci non plus sauf si ça doit justifier d'autres complexités) et des mois (des noms pour vénérer des dieux ou des empereurs, des durées aléatoires n'obéissant à aucune logique.) La complexité du système actuel demande bien plus de travail d'adaptation qu'un truc qui serait plus régulier, et les erreursproblèmes dans différents logiciels l'illustrent bien.
Concernant le maintien des années bissextiles, tu présuppose que le calendrier doit absolument être de type solaire mais il y a bien d'autres possibilités qui ne sont pas plus déconnantes. Mais bon, même dans ce cas, les calendriers décimaux (cas autrefois en Égypte puis sous la Révolution Française) n'est pas incompatible (on avait en fin d'années des jours dit intercalaires ou sansculottides en plus de la régularité des décades —semaines de dix jours— en douze mois égaux.) Et Grosclaude avait aussi fait une proposition pour avoir un système perpétuel (lire au sujet du calendrier invariable : Popular Science et Sunday Magazine ou encore Popular Astronomy par exemple) dans la même lignée que Armelin/Manin/Achelis (lire au sujet du calendrier universel : dans Time comment le religeux freine encore l'évolution, sur le site l'association de promotion la description et autres, système adopté par le CÉeS de l'ONU en 1954) Bref, on sait déjà faire si ce n'est les habituels freins irrationnels.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Je ne vois pas pourquoi des dates en négatif serait un problème, et je ne vois pas comment tu trouves qu'il y a peu d'années en négatif dans le système actuel.
Pour la neutralité, il n'est pas obligatoire que ce soit un « fait historique » ; un/une fait/convention scientifique ferait plus neutre que n'importe quelle culture religieuse, et on a déjà le TAI qui montre que ce n'est pas impossible.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Il y a toujours un début (même à un mouvement perpétuel), ce n'est pas le débat. Si le début est basé sur un consensus scientifique ça répond à la problématique initiale de ne pas avoir un choix imposé par une religion (qui serait de facto au dessus des autres et encouragerait la défiance des autres religions placées en perdantes.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Qu'on trouve une date plus précise ou une autre date n'est pas et ne sera pas un problème en soi. Me semble qu'on a eu problématique un peu similaire pour le seconde et le mètre : le changement de définition et l'augmentation de précision n'ont pas remis en cause les montres existantes. Le problème qu'on cherche à résoudre n'est pas de trouver une valeur absolue mais de convenir d'une valeur neutre commune (chose que beaucoup de réponses semblent oublier.)
Maintenant, ce ne serait pas la première fois qu'on referait un calendrier et on n'en mourra pas pour autant.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
C'est sûr que si ça passe par G..gl. ça met cette entreprise dans la position d'un état par rapport aux cartes nationales d'identité. Du coup, on peut comprendre ton questionnement et y répondre par le fait qu'ici plusieurs solutions/fournisseurs sont possibles : pas de centralisation G..gl. possible donc, sauf si tout le monde décident de faire ce choix (qui n'est pas imposé par PyPi qu'on s'entende.)
Maintenant, pour la sécurité, il faut voir/comprendre le problème actuel de l'authentification classique : quand une personne malveillante arrive à capter le mot de passe d'une autre personne bienveillante, malveillante peut commettre des exactions au nom de bienveillante ; et malheureusement on a eu beaucoup de cas qui font que ce scénario n'est plus de faible probabilité mais avéré.
Si pour accéder à tes opérations bancaires, il te fallait juste le code de ton espace client (ou de ta carte bancaire) ça sécurise …mais cette sécurité vole en éclat si quelqu'un arrive à avoir ce code. On a vu entre temps des systèmes consistant à demander plusieurs mots de passes mais avec l'inconvénient que ça multiplie les mots de passes au lieu de résoudre le vrai problème (plus les gens en ont, plus on a tendance à les noter ou à réutiliser les mêmes, au mieux certaines personnes utiliseront un gestionnaire de mot de passes mais quand c'est le gestionnaire qui est devenu accessible alors on a juste repoussé le souci et quand ça merde ça fait encore plus mal.) L'autre approche est celle des systèmes qui génère un jeton temporaire qui fait que si on arrive à attaquer une session ça ne vaudra que pour cette session et pas d'autres.) Ce n'est pas le panacée mais c'est déjà beaucoup plus sécure, sachant que les jetons ne sont pas stockés avec le mot de passe mais dynamiquement et via un autre canal : on a donc 2 facteurs qui se valident. L'idée générale est d'associer ce que le/la propriétaire légitime connait (le mot de passe) et ce que il/elle possède (par exemple, le téléphone sur lequel on va envoyer un sms contenant un code), ce qui est forcément plus sécure (bon, dans cet exemple si tu te fais voler le téléphone en même temps que les mots de passe par la même personne on revient au point de départ, sinon comparé à avant la casse est limitée) Pour en revenir à l'exemple initial, pour accéder à tes opérations bancaires, il te faut maintenant aussi bien connaître le code et présenter par exemple une pièce d'identité avant d'accéder à la salle des coffres de la banque : c'est beaucoup plus sécurisé qu'une/un simple consigne/box non ?
Il est là le rapport que tu cherches. L'accès étant plus sécurisé, il y aura moins de code malveillant venant de tierces (cela n'empêche pas le sabotage volontaire ; mais entre une personne qui saborde son npm, comme on l'a vu y a pas longtemps, et la même personne qui serait victime de bots/crackers y a un plus grand fossé.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Bonne question :-) Je ne me suis jamais personnellement penché dessus, mais j'ai remarqué que dans la plupart des distributions Linux (quand j'ai regardé), c'est organisé comme les bibliothèques partagées : plusieurs versions peuvent cohabiter. Mais, je pense que la réponse est ailleurs : PERL est l'un des rares langages de scripting à tenter de garder un maximum de compatibilité ascendante. Du coup, les distributions fournissent juste la dernière distribution stable en sachant que tous les anciens codes vont continuer à tourner.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Bof, ça reste un euphémisme puisque la référence est intrinsèquement chrétienne… Ce qu'il faudrait c'est un calendrier dont l'origine serait vraiment neutre aussi (et qui serait plus régulier tant qu'à faire)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
C'aurait pu être recyclé pour l'encyclopédie de 2nd/half life
Il a fallu qu'un romancier veuille faire une fiction plus que vraie pour foutre en l'aire un monde parallèle. Tss
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Un autre commentaire a invoqué l'implémentation de busybox… On peut ajouter, par exemple, Jerl et PLJava et perljvm comme implémentations Java. Et Parrot est pensé pour se voir interfacer n'importe quel langage (y compris Python, cf. PEP401) tandis que Raku-do permet à Perl/Raku d'implémenter n'importe quel autre langage.
Maintenant, pendant que certaines personnes s'échinent inutilement à remplacer l'un par l'autre, les principaux acteurs préfèrent faire des ponts : Inline::Python et PyPerl
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Avec un Android 5 à jour (mais donc plus maintenu) et le navigateur natif (dot je pense que c'est le support Unicode natif qui est mis en jeu) j'ai de jolis carrés à coins arrondis et bleutés (zorê du être transparent et se superposer au lieu de se mettre à côté)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Prendre le temps d'apprendre
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au journal Bloguer pour pas trop cher, avec du logiciel libre et sobrement, en 2022. Évalué à 2.
Tout à fait, mais je n'ai pas voulu être probablement mauvaise langue en pointant la mauvaise volonté (sans preuve indiscutable …même s'il est vrai que je ne donne pas d'élément d'identification ici) Plus précisément, j'ai cru déceler avec les deux derniers avec qui je l'ai vécu plus une volonté de ne pas comprendre Git (et de ne pas apprendre de nouveaux contextes et façon de faire en général) que de la volonté d'emmerder (mais au final quand ça fout la grouille ça y ressemble un peu pour les anciens dont je faisais partie.) :-( Ces gens faisaient le minimum syndical…
Dans la même boîte, avec l'équipe d'avant, on a vu aussi des souci (d'où le fait que je me dis que Git n'est pas trivial si on n'est pas correctement pris en main, ce qui ne prend que dix à quinze minutes pour les commandes de bases appliquées à un dépôt existant) mais la personne s'est vite rendu compte que ça n'allait pas et a demandé de l'aide aux collègues …et aujourd'hui dans une autre boîte le même sys-admin git les doigts dans le nez :-D
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: AsciiDoc et les tableaux
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien Les limites de Markdown (pour rédiger de la documentation) face aux capacités d’Asciidoc. Évalué à 2. Dernière modification le 19 juillet 2022 à 19:29.
Que reproches-tu à ses tableaux (que je trouve quand même plus avancés que Markdown) ?
https://docs.asciidoctor.org/asciidoc/latest/tables/build-a-basic-table/
https://blog.mrhaki.com/2014/11/awesome-asciidoctor-changing-grid-and.html
(c'est son principe qu'à repris la syntaxe MediaWiki et on voit que tous les cas courants de tableaux sont présents dans Wikipédia.) Quel cas manque-t-il à ton usage ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: txt2tags
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien Les limites de Markdown (pour rédiger de la documentation) face aux capacités d’Asciidoc. Évalué à 3.
Exactement, la raison pour laquelle je dis que la syntaxe Wiki est mieux fichue (en plus d'être plus riche de base) que Markdown ! Malheureusement, il y a beaucoup de dialectes qui ont l'avantage d'être plus riche que Creole (mais n'est-ce pas le même souci avec toutes les « saveurs » de l'autre qui font que je ne peux pas juste prendre mes écrits pour Github ou Gitlab et les mettre sur Linuxfr juste pour prendre cet exemple.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: une seule solution
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien Facebook chiffre les liens pour déjouer le nettoyage d'URL. Évalué à 5.
Je doute aussi que le coup des URLs parle à grand monde, mais on propos est que à chaque égratignure on a une excuse de plus pour se barrer… Et il faudrait lire la longue liste des chefs d'accusations aux aveugles au lieu de les encourager à la complaisance ou de se dédouaner de nourrir le système à base de « pas le choix, on a trop d'infos vitales dessus blah blah » Comme expliqué dans un autre commentaire, d'autres ont fait le saut et la mort sociale dont on les menacé en cas de sortie de la secte/matrice n'a pas eu lieu.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Prendre le temps d'apprendre
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au journal Bloguer pour pas trop cher, avec du logiciel libre et sobrement, en 2022. Évalué à 2.
Pour être dans le métier (enfin jusqu'à il y a peu), je vois (ou plutôt, maintenant, j'ai vu) beaucoup d'admins pour qui c'est compliqué : pas de
pullavant de modifier leur local poussiéreux puis, éventuellement depushet écraser tout ce qui a été fait entre temps, quand ils prennent le temps de bien faire, c'est panique à bord parce-qu'ils ont modifié avant de récupérer le distant et qu'il y a un conflit qu'ils savent pas résoudre, etc.La mauvaise expérience c'est presque sûr. Je trouve honnête de ne pas forcer et d'admettre qu'on n'a pas compris que de jouer avec les données et foutre n'importe quoi (par contre dommage de servir cela avec de mauvaises excuses mais peut-être que l'absence du bon diagnostique peut expliquer la chose.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Du coté des historiens
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien Calendrier républicain (script de conversion des dates). Évalué à 2.
https://linuxfr.org/users/linkdd/journaux/letlang-faire-la-difference-entre-un-nombre-et-une-quantite#comment-1887035
Comme mentionné dans d'autres commentaires il faut des bibliothèques dédiées, qui ne sont pas si simples malgré cela. et évitent les mois dans la mesure du possible.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Du coté des historiens
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien Calendrier républicain (script de conversion des dates). Évalué à 1.
Je n'accuse pas, je constate. :)
Je reformule : dans lequel de mes liens as-tu lu que juin tombe de temps en temps en hiver ? Les trois exemples que j'ai pris sont calés sur 365 jours et commencent le premier janvier : les saisons théoriques tombent encore dans les mêmes périodes, ou alors il y a un passage dont j'ai eu une mauvaise compréhension ?
Les difficultés liées aux irrégularités des mots ont souvent été évoquées ici, et ce n'est pas pour rien que la gestion des certains calculs de dates fait une grosse partie du code qui n'est pas exempt de bogues. Tout con par exemple, comment tu ajoutes deux mois à n'importe quelle date …sans devoir énumérer plein de cas particuliers ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# une seule solution
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien Facebook chiffre les liens pour déjouer le nettoyage d'URL. Évalué à 8.
L'article conclue par « Users could avoid Facebook, but that may not be possible all the time. » ; mais moi je dis dis juste que « Users should avoid Facebook, full stop. »
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# plaidoyer pour SPIP
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au journal Bloguer pour pas trop cher, avec du logiciel libre et sobrement, en 2022. Évalué à 8.
Au chapitre des fausses pistes, tu indiques :
Tout d'abord, concernant la base de données, tu n'as besoin d'un SGBD supportant des connexions multiples si tu es seul/seule à écrire du contenu (cas d'un blog perso) et/ou s'il y a très peu de comptes et de publications (j'entends par là que vous n'êtes pas une dizaine à publier une foule d'articles toutes les heures ?) Ça tombe bien, SPIP supporte les moteurs PostgreSQL, MySQL/mariaDB, SQLite …ce dernier répond très bien à ta problématique : quand tu transfères ton site, le fichier de bdd l'est aussi et ce ne sont pas des opérations à côté et pas plus de ressources.
Ayant souvent du contenu structuré, j'ai toujours détesté son absence dans Wordpress ; et je vois beaucoup de site basés dessus qui sont obligés de faire des contournements du système de catégorisations ou d'installer des plugins. Comme tu n'as pas ce besoin, pas de souci : il te faut juste créer une rubrique racine fourre-tout que tu appelleras blog qui seule sera affichée par ton squelette. Si demain tu changes d'avis, ton site peut facilement évoluer (mais on ne va pas détailler cet aspect qui est loin de tes préoccupations.)
Il existe déjà des squelettes si tu n'as pas d'idée ou de temps pour t'en faire un sur mesure → https://contrib.spip.net/Squelettes-pour-blog
Les catégories et étiquettes existent de l'autre côté et s'appellent groupes de mots et mot-clés. Leurs pages d'affichage fonctionnent de la même façon avec la plupart des squelettes évoqués, mais tu es libre de faire à ta sauce sans sortir l'artillerie de dev PHP comme en face. D'ailleurs, faire des boucles liées et sur mesure est dans l'ADN de SPIP et il te suffit d'adapter ton squelette et d'utiliser les nombreux plugins disponibles pour te simplifier l'existence.
Pour les fonctionnalités qui seraient imposées, ce n'est pas du tout le cas. L'installation par défaut ne te demande que le titre et le texte de l'article. Mieux, tout juste après l'installation, à la première connexion, tu es invité/invitée à tout configurer à ton goût et tu verras que rien n'est imposé.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Du coté des historiens
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien Calendrier républicain (script de conversion des dates). Évalué à 1.
Parmi toutes les propositions possibles j'ai listé celles qui, solides, qui remplissent tes critères. Si tu avais pris la peine de regarder tu verrais que ton juin ne tombe jamais en hiver, mais bon c'est plus facile un raisonnement non basé sur les faits.
Passer de sept mois irréguliers à zéro mois irrégulier et un ou deux jours particuliers c'est sûr que ce n'est pas plus régulier. C'est une façon de voir les choses ; je ne pige pas mais pourquoi pas ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Je vois pas le rapport!
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse à la dépêche PyPI déploie le système 2FA pour les projets critiques écrits en Python. Évalué à 3.
Oui, un cas isolé ici. Mais ma réponse était globale, pour répondre par rapport à l'apport du MFA, et ne ciblait pas (que) PyPi.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Si on ne comprend pas c'est que
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse à la dépêche Sortie de darktable 4.0.0 : une présentation 100 % subjective. Évalué à 3.
Tu as donné les réponses dans les questions ;-)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Du coté des historiens
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien Calendrier républicain (script de conversion des dates). Évalué à 2. Dernière modification le 17 juillet 2022 à 20:24.
→ https://qntm.org/calendar
Juste une liste d'excuses pour la résistance aux changements, avec un grand focus sur l'année solaire (365 jours, bissextiles, tout ça, voir mon autre commentaire…)
La vrai raison du rejet d'un calendrier plus cartésien en France s'appelle Napoléon (qui l'a aboli au 1er janvier 1806 : si ça ne tenait qu'à lui on aurait probablement eu le pied napoléonien au lieu du mètre…) Zut, on n'est plus vendredi sur aucun fuseau horaire.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Du coté des historiens
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien Calendrier républicain (script de conversion des dates). Évalué à 1.
Pour un calendrier régulier, je n'entends pas forcément l'abolition des années bissextiles mais d'avoir un système globalement plus régulier dans le comptage des semaines (la semaine de 5 jours est un exemple, 7 ne me pose pas de souci non plus sauf si ça doit justifier d'autres complexités) et des mois (des noms pour vénérer des dieux ou des empereurs, des durées aléatoires n'obéissant à aucune logique.) La complexité du système actuel demande bien plus de travail d'adaptation qu'un truc qui serait plus régulier, et les
erreursproblèmes dans différents logiciels l'illustrent bien.Concernant le maintien des années bissextiles, tu présuppose que le calendrier doit absolument être de type solaire mais il y a bien d'autres possibilités qui ne sont pas plus déconnantes. Mais bon, même dans ce cas, les calendriers décimaux (cas autrefois en Égypte puis sous la Révolution Française) n'est pas incompatible (on avait en fin d'années des jours dit intercalaires ou sansculottides en plus de la régularité des décades —semaines de dix jours— en douze mois égaux.) Et Grosclaude avait aussi fait une proposition pour avoir un système perpétuel (lire au sujet du calendrier invariable : Popular Science et Sunday Magazine ou encore Popular Astronomy par exemple) dans la même lignée que Armelin/Manin/Achelis (lire au sujet du calendrier universel : dans Time comment le religeux freine encore l'évolution, sur le site l'association de promotion la description et autres, système adopté par le CÉeS de l'ONU en 1954) Bref, on sait déjà faire si ce n'est les habituels freins irrationnels.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Du coté des historiens
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien Calendrier républicain (script de conversion des dates). Évalué à 1.
Je ne vois pas pourquoi des dates en négatif serait un problème, et je ne vois pas comment tu trouves qu'il y a peu d'années en négatif dans le système actuel.
Pour la neutralité, il n'est pas obligatoire que ce soit un « fait historique » ; un/une fait/convention scientifique ferait plus neutre que n'importe quelle culture religieuse, et on a déjà le TAI qui montre que ce n'est pas impossible.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Du coté des historiens
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien Calendrier républicain (script de conversion des dates). Évalué à 2.
Il y a toujours un début (même à un mouvement perpétuel), ce n'est pas le débat. Si le début est basé sur un consensus scientifique ça répond à la problématique initiale de ne pas avoir un choix imposé par une religion (qui serait de facto au dessus des autres et encouragerait la défiance des autres religions placées en perdantes.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Du coté des historiens
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien Calendrier républicain (script de conversion des dates). Évalué à 2.
Qu'on trouve une date plus précise ou une autre date n'est pas et ne sera pas un problème en soi. Me semble qu'on a eu problématique un peu similaire pour le seconde et le mètre : le changement de définition et l'augmentation de précision n'ont pas remis en cause les montres existantes. Le problème qu'on cherche à résoudre n'est pas de trouver une valeur absolue mais de convenir d'une valeur neutre commune (chose que beaucoup de réponses semblent oublier.)
Maintenant, ce ne serait pas la première fois qu'on referait un calendrier et on n'en mourra pas pour autant.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Je vois pas le rapport!
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse à la dépêche PyPI déploie le système 2FA pour les projets critiques écrits en Python. Évalué à 2.
C'est sûr que si ça passe par G..gl. ça met cette entreprise dans la position d'un état par rapport aux cartes nationales d'identité. Du coup, on peut comprendre ton questionnement et y répondre par le fait qu'ici plusieurs solutions/fournisseurs sont possibles : pas de centralisation G..gl. possible donc, sauf si tout le monde décident de faire ce choix (qui n'est pas imposé par PyPi qu'on s'entende.)
Maintenant, pour la sécurité, il faut voir/comprendre le problème actuel de l'authentification classique : quand une personne malveillante arrive à capter le mot de passe d'une autre personne bienveillante, malveillante peut commettre des exactions au nom de bienveillante ; et malheureusement on a eu beaucoup de cas qui font que ce scénario n'est plus de faible probabilité mais avéré.
Si pour accéder à tes opérations bancaires, il te fallait juste le code de ton espace client (ou de ta carte bancaire) ça sécurise …mais cette sécurité vole en éclat si quelqu'un arrive à avoir ce code. On a vu entre temps des systèmes consistant à demander plusieurs mots de passes mais avec l'inconvénient que ça multiplie les mots de passes au lieu de résoudre le vrai problème (plus les gens en ont, plus on a tendance à les noter ou à réutiliser les mêmes, au mieux certaines personnes utiliseront un gestionnaire de mot de passes mais quand c'est le gestionnaire qui est devenu accessible alors on a juste repoussé le souci et quand ça merde ça fait encore plus mal.) L'autre approche est celle des systèmes qui génère un jeton temporaire qui fait que si on arrive à attaquer une session ça ne vaudra que pour cette session et pas d'autres.) Ce n'est pas le panacée mais c'est déjà beaucoup plus sécure, sachant que les jetons ne sont pas stockés avec le mot de passe mais dynamiquement et via un autre canal : on a donc 2 facteurs qui se valident. L'idée générale est d'associer ce que le/la propriétaire légitime connait (le mot de passe) et ce que il/elle possède (par exemple, le téléphone sur lequel on va envoyer un sms contenant un code), ce qui est forcément plus sécure (bon, dans cet exemple si tu te fais voler le téléphone en même temps que les mots de passe par la même personne on revient au point de départ, sinon comparé à avant la casse est limitée) Pour en revenir à l'exemple initial, pour accéder à tes opérations bancaires, il te faut maintenant aussi bien connaître le code et présenter par exemple une pièce d'identité avant d'accéder à la salle des coffres de la banque : c'est beaucoup plus sécurisé qu'une/un simple consigne/box non ?
Il est là le rapport que tu cherches. L'accès étant plus sécurisé, il y aura moins de code malveillant venant de tierces (cela n'empêche pas le sabotage volontaire ; mais entre une personne qui saborde son npm, comme on l'a vu y a pas longtemps, et la même personne qui serait victime de bots/crackers y a un plus grand fossé.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Vraie question
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien why PERL is still relevant in 2022?. Évalué à 3.
Bonne question :-) Je ne me suis jamais personnellement penché dessus, mais j'ai remarqué que dans la plupart des distributions Linux (quand j'ai regardé), c'est organisé comme les bibliothèques partagées : plusieurs versions peuvent cohabiter. Mais, je pense que la réponse est ailleurs : PERL est l'un des rares langages de scripting à tenter de garder un maximum de compatibilité ascendante. Du coup, les distributions fournissent juste la dernière distribution stable en sachant que tous les anciens codes vont continuer à tourner.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Version courte
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien why PERL is still relevant in 2022?. Évalué à 4.
Février 1991, soit 31 ans ; c'est sûr que ce n'est pas vieux et très moderne.
Février 1988, juste 3 ans de plus ; c'est sûr que ça fait archi vieux n'est-ce pas ?
Juin 1995, soit 27 ans, c'est encore plus vieux que 31… dans la distorsion de vue.
Quand on veut noyer son animal…
Mis à part les sentiments tirés du chapeau, peux-tu développer factuellement ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Ruby
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien why PERL is still relevant in 2022?. Évalué à 4.
C'est bon, on a compris que tu es juste anti.
Au cas où tu ne le saurais pas, tu crois que ce n'est plus en usage et pourtant : on continue de le lister (parmi sept autres à considérer) en 2022 ; ailleurs c'est en dixième position juste avant C++ pour 2022 ; même github montre une activité importante pour un mort. Bref, on te laisse à tes croyances.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Du coté des historiens
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien Calendrier républicain (script de conversion des dates). Évalué à 2.
Bof, ça reste un euphémisme puisque la référence est intrinsèquement chrétienne… Ce qu'il faudrait c'est un calendrier dont l'origine serait vraiment neutre aussi (et qui serait plus régulier tant qu'à faire)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Réaction sur Wikipédia francophone
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien Elle s’ennuyait, jusqu’à devenir le pire ennemi de Wikipédia (le titre est pourri, dommage). Évalué à 5.
C'aurait pu être recyclé pour l'encyclopédie de 2nd/half life
Il a fallu qu'un romancier veuille faire une fiction plus que vraie pour foutre en l'aire un monde parallèle. Tss
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Vraie question
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au lien why PERL is still relevant in 2022?. Évalué à 2.
Comme répondu ailleurs, la plupart des langages de script sont compilables aussi, y compris Perl
https://www.marcbilodeau.com/compiling-perl/
Un autre commentaire a invoqué l'implémentation de busybox… On peut ajouter, par exemple, Jerl et PLJava et perljvm comme implémentations Java. Et Parrot est pensé pour se voir interfacer n'importe quel langage (y compris Python, cf. PEP401) tandis que Raku-do permet à Perl/Raku d'implémenter n'importe quel autre langage.
Maintenant, pendant que certaines personnes s'échinent inutilement à remplacer l'un par l'autre, les principaux acteurs préfèrent faire des ponts : Inline::Python et PyPerl
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: U+20E3
Posté par Gil Cot ✔ (site web personnel, Mastodon) . En réponse au message [résolu] markdown indication touches. Évalué à 2.
Avec un Android 5 à jour (mais donc plus maintenu) et le navigateur natif (dot je pense que c'est le support Unicode natif qui est mis en jeu) j'ai de jolis carrés à coins arrondis et bleutés (zorê du être transparent et se superposer au lieu de se mettre à côté)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume