D'ailleurs, puisqu'on parle médecine, on pourra saluer le côté progressiste de la communauté du porno, qui bien avant l'écriture inclusive a popularisé le terme de "doctoresse".
Sur les copies d'écran, le fond de page est également noir. C'est curieux : ça correspond à un choix de configuration ?
Quand je rédige un document, il reste toujours possible/probable que je doive l'imprimer. Comment je sais à quoi ça va ressembler dans ces conditions ? Le gras ne rend pas du tout pareil en blanc sur noir et en noir sur blanc, les choix de couleurs vont être beaucoup plus difficile si je travaille en inverse.
Je vais télécharger de ce pas et essayer ça par curiosité. Par curiosité uniquement, puisque de toute façon je n'utilise pas le mode sombre :-).
J'ai l'impression que ce que tu cherches, c'est un CMDB.
Mais effectivement, les solutions de CMDB ne s'arrêtent généralement pas juste à tes composants logiciels, ce sont des solutions qui gèrent tous tes "actifs" (assets) informatiques.
tout est déjà "informatisé" ; quand un truc est fait avec des macros Excel qui s'échangent des fichiers sur un disque partagé avec des actions manuelles à toutes les étapes, c'est déjà "informatisé".
pour le même sujet, c'est déjà "dématéralisé" : plus de paperasse, des "bases de données" sous Excel et un process à base d'emails ou de chat.
moi je me contente d'essayer de "l'automatiser" ; ce qui reste étrange puisqu'il est déjà "informatisé" (="traitement automatique de l'information"). Du coup, j'essaye plus généralement de "l'industrialiser". Mot auquel souscrit également mon management.
Après, c'est pas le pire, le mot existait déjà avec un sens pas si éloigné, et la définition historique de disruption collait très bien ("Rupture, fracture").
Le mail est ouvert, oui. Et tellement facile à pirater.
Mes factures ne concernent que moi, j'ai pas envie que n'importe quel hacker bien outillé puisse se les procurer.
D'ailleurs, même les mails qui sont sous la forme "vous avez reçu une facture, cliquez ici pour la récupérer" sont déjà la source de sueurs froides de tous les experts en sécurité. Ca habitue l'utilisateur lambda à cliquer sur des liens dans ses mails. Alors que la bonne pratique, encore plus pénible pour l'utilisateur, c'est "vous avez reçu une facture, allez sur notre site web dont vous avez déjà l'adresse pour la récupérer".
Tant qu'à rêver, moi j'ai un autre rêve. Avoir la possibilité de demander l'envoi des factures (et autres documents) sur un espace de stockage sécurisé. Si je suis motivé, j'auto-herberge ce service. Sinon, je peux faire appel à des prestataires; type "ma banque", ou "mon assurreur", ou "mon fourniseur de cloud"…
Avec une API standard qui permet de gérer liste blanche/liste noire, l'envoi de documents, la consultation des documents, la définition de la durée de rétention, des règles de classement automatique, etc…
Et pour passer du rêve à l'utopie délirante, ce type de service pourrait être fourni par l'état pour les plus démunis qui ne peuvent pas se payer ce type de service (critère du genre "non imposable").
Il y a un problème similaire que j'aimerais voir traité, mais avec des considérations de sécurités qui le rendent encore plus difficile. Je parle bien entendu d'une API normée pour accéder à des comptes bancaires.
Mais ça existe ! En Grande-Bretagne, c'est OpenBanking, pour le reste de l'Europe c'est PSD2. En général, les banques proposent au moins 2 APIs :
une pour permettre les paiements : PISP (Payment Initiation Service Providers)
une pour consulter la balance des comptes et la liste des transactions: AISP (Account Information Service Providers)
La réglementation n'est pas venue avec une spécification d'API, mais il y a un standard de fait : STET. Tu peux aller voir là : https://www.stet.eu/en/psd2/.
Surtout que de mémoire, en français il y a le superbe "mercatique" qui existe.
Honnêtement, ce mot doit être employé deux fois par an, et sans doute par erreur ; des étudiants qui le découvrent au hasard d'une recherche wikipedia…
Plus la charge va être forte plus le cache va jouer à priori
Si tu fais surtout de l'écriture, pas tant que ça… Si tu fais de la lecture dans une très grosse base de données, avec une bonne distribution des lectures (genre chaque utilisateur tape dans ses propres enregistrements), pas tant que ça.
Maintenant, ça dépend de plein de paramètres - et notamment de quelle infrastructure tu disposes. Si tu est quasi-illimité en mémoire, tu peux. Mais je doute que le modèle (économique) du serverless soit alors le plus pertinent. Parce que le cache en lecture, il faut le remplir avant qu'il puisse être efficace…
Faut composer avec l'existant. Angular/React/Vue et toute la clique. Avec leur environnement de développement merdique basé sur NodeJS et NPM, qui fait qu'il te faut télécharger 3 Tera-octets sur ton disque pour créer une app web de type "Hello World" sans que ça choque personne.
D'où mon commentaire précédent : j'attend encore que le futur arrive :-(.
Du coup, ça va bien avec les autres services dits "serverless". Parfait pour démarrer et des petits volumes / usage rare, mais à oublier quand on commence à taper sur des gros volumes et/ou une charge constante.
Mais… euh… question sans doute idiote, mais S3, c'est pas essentiellement accessible par des APIs REST? Y'a moyen d'avoir un accès plus bas niveau ?
Parce que sinon, pour gérer le stockage "live" d'une base de données, c'est quand même pas ultra-optimal, non ? Quand le journal de transaction est appliqué, c'est essentiellement des écritures en accès aléatoire.
Ou alors cette solution est essentiellement pour des (toutes) petites bases de données ?
Sur le schéma d'architecture, je n'ai pas trouvé d'information éclairante à ce sujet.
OK, mais c'est quand même recourir au point médian dans certains cas ; quand il n'y a pas une formulation neutre facile à mettre en œuvre.
Dans d'autres cas, c'est utiliser un mot qu'on n'aurait pas utilisé autrement, mais qu'on prend quand même. Pas parce qu'il est plus ou autant pertinent, mais parce qu'il est neutre.
Ca me fait vraiment penser à la discrimination positive. Encore une fois, je pense que ça finit par desservir la cause que ça prétend aider.
Quant à donner une définition de l'écriture inclusive, je suis comme tout le monde : je n'ai pas de définition formelle. Je me contente de voir autour de moi ce que les gens mettent là-dedans. Pour l'instant, ça reste un mot flou - inutile de lui coller un sens précis tant qu'il n'y a pas consensus. Comme on dit : c'est l'usage qui fait la langue.
Et pour HTML5 et toute la clique, je considère, voire j'espère, que ce n'est pas l'état final de l'art. Car pour l'instant, ça reste de la grosse bouillasse.
La bonne manière de faire des applications "internet" (http/web ou pas) reste à inventer à mes yeux.
Pour clarifier, les 3 points que je citais sont les objectifs que je me fixerai.
Et pour être encore plus précis, je considère que l'écriture inclusive qu'on croise actuellement…
- essaye de mettre à égalité masculin et féminin (donc objectif atteint ici)
- est trop difficile à lire et à écrire
- représente une rupture trop importante (introduction d'une nouvelle ponctuation, rendu audio lourd pour les non/malvoyants)
Ploum a expliqué plus haut que l'usage de l'écriture inclusive dans cette nouvelle découlait d'une approche artistique, et c'est vrai que ça colle bien au sujet, donc chapeau bas.
Pour ma part, je partage aussi les autres avis : si je devais lire ça en permanence, ça me fatiguerait beaucoup. Très désagréable, lourd à l'écriture et à la lecture, toujours à se demander si c'est une faute de frappe ou intentionnel, bref ça dessert la cause que c'est supposé défendre.
Je suis toujours à la recherche d'une réforme de la langue française qui…
ne mettrait effectivement pas le masculin sur un piédestal
n'impliquerait pas un gros effort à la lecture / écriture
ne serait pas une rupture trop importante par rapport à l'existant, car c'est ce qui a tué la réforme Toubon et tuera toute réforme trop violente
Sur l'analyse d'impact en 2050, pour les scénarios Negawatt, je vois encore du nucléaire (ça reste même le plus gros poste sur la version 2022). https://metawatt.fr/impact/production/final
Du coup, la page sur l'analyse d'impact, elle veut dire quoi exactement ? Si on regarde le second graphique, ça indique "production totale de aujourd'hui jusqu'en 2050". Donc c'est du cumulé ? Et c'est vrai aussi pour le premier graphique même si il ne le dit pas ?
Je suis plutôt d’accord avec la vision « le dogme c’est mal ».
Mais c’est quoi qui te gêne avec l’idée du « 1 repo pour 1 app » ?
Et tu ne penses pas que pour les logs, pour une exécution dans un cloud type kubernetes, le point 11 soit également valide ? Dans le principe, on doit généralement considérer qu’on n’a aucun stockage à disposition puisque en cas du destruction du node, tout peut et va disparaître.
J’aimerais comprendre comment le mec derrière Phoronix, qui signe tous ou pratiquement tous les articles de ce site, fait pour suivre tous ces sujets.
Là il écrit « j’étais tranquillement en train de regarder tous les changements de code dans le code de Chrome quand je suis tombé sur ce commentaire ».
Boudiou ! On a l’impression qu’il fait ça au petit déjeuner avant sa demi-heure quotidienne de LKML. Certes il est journaliste et tout ça est dans son domaine de prédilection, mais j’ai quand même envie de dire « respect ».
[^] # Re: Interdire les sites pornographiques tout court.
Posté par Dring . En réponse au lien La France prévoit de bloquer l'accès aux sites pornographiques pour les mineurs - letemps.ch. Évalué à 7.
D'ailleurs, puisqu'on parle médecine, on pourra saluer le côté progressiste de la communauté du porno, qui bien avant l'écriture inclusive a popularisé le terme de "doctoresse".
[^] # Re: Et
Posté par Dring . En réponse au lien LibreOffice 7.5 Released With Improved Dark Mode, Better PDF Exporting - phoronix. Évalué à 3.
Sur les copies d'écran, le fond de page est également noir. C'est curieux : ça correspond à un choix de configuration ?
Quand je rédige un document, il reste toujours possible/probable que je doive l'imprimer. Comment je sais à quoi ça va ressembler dans ces conditions ? Le gras ne rend pas du tout pareil en blanc sur noir et en noir sur blanc, les choix de couleurs vont être beaucoup plus difficile si je travaille en inverse.
Je vais télécharger de ce pas et essayer ça par curiosité. Par curiosité uniquement, puisque de toute façon je n'utilise pas le mode sombre :-).
# Y'a ceux qui sachent...
Posté par Dring . En réponse au journal Un souci…. Évalué à 5.
…et ceux qui croivent sachoir !
# CMDB ?
Posté par Dring . En réponse au message Logiciel d'inventaire de Logiciel. Évalué à 3.
J'ai l'impression que ce que tu cherches, c'est un CMDB.
Mais effectivement, les solutions de CMDB ne s'arrêtent généralement pas juste à tes composants logiciels, ce sont des solutions qui gèrent tous tes "actifs" (assets) informatiques.
Après, est-ce que c'est un problème ?
[^] # Re: très sincèrement...
Posté par Dring . En réponse au sondage Quel mot de franglais vous horripile le plus ?. Évalué à 5.
Dans mon univers…
tout est déjà "informatisé" ; quand un truc est fait avec des macros Excel qui s'échangent des fichiers sur un disque partagé avec des actions manuelles à toutes les étapes, c'est déjà "informatisé".
pour le même sujet, c'est déjà "dématéralisé" : plus de paperasse, des "bases de données" sous Excel et un process à base d'emails ou de chat.
moi je me contente d'essayer de "l'automatiser" ; ce qui reste étrange puisqu'il est déjà "informatisé" (="traitement automatique de l'information"). Du coup, j'essaye plus généralement de "l'industrialiser". Mot auquel souscrit également mon management.
[^] # Re: il en manque
Posté par Dring . En réponse au sondage Quel mot de franglais vous horripile le plus ?. Évalué à 3.
Dans le sens utilisé de nos jours, c'est bien un anglicisme, cf. https://fr.wiktionary.org/wiki/disruptif.
Après, c'est pas le pire, le mot existait déjà avec un sens pas si éloigné, et la définition historique de disruption collait très bien ("Rupture, fracture").
[^] # Re: Et le Mail
Posté par Dring . En réponse au journal Une API normée pour accéder aux factures (1ere étape). Évalué à 2.
C'est pas du tout mon rêve ! Gâcheur de rêve !
Moi, je vise avant tout une norme, avec plusieurs implémentations possibles.
[^] # Re: Et le Mail
Posté par Dring . En réponse au journal Une API normée pour accéder aux factures (1ere étape). Évalué à 7.
Le mail est ouvert, oui. Et tellement facile à pirater.
Mes factures ne concernent que moi, j'ai pas envie que n'importe quel hacker bien outillé puisse se les procurer.
D'ailleurs, même les mails qui sont sous la forme "vous avez reçu une facture, cliquez ici pour la récupérer" sont déjà la source de sueurs froides de tous les experts en sécurité. Ca habitue l'utilisateur lambda à cliquer sur des liens dans ses mails. Alors que la bonne pratique, encore plus pénible pour l'utilisateur, c'est "vous avez reçu une facture, allez sur notre site web dont vous avez déjà l'adresse pour la récupérer".
Tant qu'à rêver, moi j'ai un autre rêve. Avoir la possibilité de demander l'envoi des factures (et autres documents) sur un espace de stockage sécurisé. Si je suis motivé, j'auto-herberge ce service. Sinon, je peux faire appel à des prestataires; type "ma banque", ou "mon assurreur", ou "mon fourniseur de cloud"…
Avec une API standard qui permet de gérer liste blanche/liste noire, l'envoi de documents, la consultation des documents, la définition de la durée de rétention, des règles de classement automatique, etc…
Et pour passer du rêve à l'utopie délirante, ce type de service pourrait être fourni par l'état pour les plus démunis qui ne peuvent pas se payer ce type de service (critère du genre "non imposable").
[^] # Re: Force à toi
Posté par Dring . En réponse au journal Une API normée pour accéder aux factures (1ere étape). Évalué à 10.
Mais ça existe ! En Grande-Bretagne, c'est OpenBanking, pour le reste de l'Europe c'est PSD2. En général, les banques proposent au moins 2 APIs :
La réglementation n'est pas venue avec une spécification d'API, mais il y a un standard de fait : STET. Tu peux aller voir là : https://www.stet.eu/en/psd2/.
[^] # Re: très sincèrement...
Posté par Dring . En réponse au sondage Quel mot de franglais vous horripile le plus ?. Évalué à 7.
Surtout que de mémoire, en français il y a le superbe "mercatique" qui existe.
Honnêtement, ce mot doit être employé deux fois par an, et sans doute par erreur ; des étudiants qui le découvrent au hasard d'une recherche wikipedia…
Du coup, ça reste "marketing" pour tout le monde.
[^] # Re: S3 ?
Posté par Dring . En réponse au journal Neon : Postgresql serverless avec branches . Évalué à 3.
Ouais, bof…
Si tu fais surtout de l'écriture, pas tant que ça… Si tu fais de la lecture dans une très grosse base de données, avec une bonne distribution des lectures (genre chaque utilisateur tape dans ses propres enregistrements), pas tant que ça.
Maintenant, ça dépend de plein de paramètres - et notamment de quelle infrastructure tu disposes. Si tu est quasi-illimité en mémoire, tu peux. Mais je doute que le modèle (économique) du serverless soit alors le plus pertinent. Parce que le cache en lecture, il faut le remplir avant qu'il puisse être efficace…
[^] # Re: Sinon il faut utiliser quoi ?
Posté par Dring . En réponse au sondage La pire tentative de web dynamique fut.... Évalué à 3.
Faut composer avec l'existant. Angular/React/Vue et toute la clique. Avec leur environnement de développement merdique basé sur NodeJS et NPM, qui fait qu'il te faut télécharger 3 Tera-octets sur ton disque pour créer une app web de type "Hello World" sans que ça choque personne.
D'où mon commentaire précédent : j'attend encore que le futur arrive :-(.
[^] # Re: S3 ?
Posté par Dring . En réponse au journal Neon : Postgresql serverless avec branches . Évalué à 3.
Du coup, ça va bien avec les autres services dits "serverless". Parfait pour démarrer et des petits volumes / usage rare, mais à oublier quand on commence à taper sur des gros volumes et/ou une charge constante.
# S3 ?
Posté par Dring . En réponse au journal Neon : Postgresql serverless avec branches . Évalué à 5.
Mais… euh… question sans doute idiote, mais S3, c'est pas essentiellement accessible par des APIs REST? Y'a moyen d'avoir un accès plus bas niveau ?
Parce que sinon, pour gérer le stockage "live" d'une base de données, c'est quand même pas ultra-optimal, non ? Quand le journal de transaction est appliqué, c'est essentiellement des écritures en accès aléatoire.
Ou alors cette solution est essentiellement pour des (toutes) petites bases de données ?
Sur le schéma d'architecture, je n'ai pas trouvé d'information éclairante à ce sujet.
[^] # Re: L'écriture inclusive, c'est de la merde.
Posté par Dring . En réponse au journal Quelques joyeusetés que nous réserve le futur…. Évalué à 2.
OK, mais c'est quand même recourir au point médian dans certains cas ; quand il n'y a pas une formulation neutre facile à mettre en œuvre.
Dans d'autres cas, c'est utiliser un mot qu'on n'aurait pas utilisé autrement, mais qu'on prend quand même. Pas parce qu'il est plus ou autant pertinent, mais parce qu'il est neutre.
Ca me fait vraiment penser à la discrimination positive. Encore une fois, je pense que ça finit par desservir la cause que ça prétend aider.
Quant à donner une définition de l'écriture inclusive, je suis comme tout le monde : je n'ai pas de définition formelle. Je me contente de voir autour de moi ce que les gens mettent là-dedans. Pour l'instant, ça reste un mot flou - inutile de lui coller un sens précis tant qu'il n'y a pas consensus. Comme on dit : c'est l'usage qui fait la langue.
[^] # Re: Flash
Posté par Dring . En réponse au sondage La pire tentative de web dynamique fut.... Évalué à 5.
Moi aussi j'ai longuement hésité.
Et pour HTML5 et toute la clique, je considère, voire j'espère, que ce n'est pas l'état final de l'art. Car pour l'instant, ça reste de la grosse bouillasse.
La bonne manière de faire des applications "internet" (http/web ou pas) reste à inventer à mes yeux.
[^] # Re: L'écriture inclusive, c'est de la merde.
Posté par Dring . En réponse au journal Quelques joyeusetés que nous réserve le futur…. Évalué à 2.
Pour clarifier, les 3 points que je citais sont les objectifs que je me fixerai.
Et pour être encore plus précis, je considère que l'écriture inclusive qu'on croise actuellement…
- essaye de mettre à égalité masculin et féminin (donc objectif atteint ici)
- est trop difficile à lire et à écrire
- représente une rupture trop importante (introduction d'une nouvelle ponctuation, rendu audio lourd pour les non/malvoyants)
# On a des choses à apprendre...
Posté par Dring . En réponse au lien Stockage, mobilité, bureaux-abris… Face aux coupures de courant, la tech ukrainienne s’organise. Évalué à 5.
…pour préparer les jours froids de cet hier…
[^] # Re: L'écriture inclusive, c'est de la merde.
Posté par Dring . En réponse au journal Quelques joyeusetés que nous réserve le futur…. Évalué à 2. Dernière modification le 29 novembre 2022 à 15:45.
Ploum a expliqué plus haut que l'usage de l'écriture inclusive dans cette nouvelle découlait d'une approche artistique, et c'est vrai que ça colle bien au sujet, donc chapeau bas.
Pour ma part, je partage aussi les autres avis : si je devais lire ça en permanence, ça me fatiguerait beaucoup. Très désagréable, lourd à l'écriture et à la lecture, toujours à se demander si c'est une faute de frappe ou intentionnel, bref ça dessert la cause que c'est supposé défendre.
Je suis toujours à la recherche d'une réforme de la langue française qui…
# Explications ?
Posté par Dring . En réponse au lien Metawatt - Comparez les scénarios de transition énergétique électrique. Évalué à 2.
Je suis pas sûr tout suivre.
Sur l'analyse d'impact en 2050, pour les scénarios Negawatt, je vois encore du nucléaire (ça reste même le plus gros poste sur la version 2022).
https://metawatt.fr/impact/production/final
Par contre, dans le détail du scénario, pas de nucléaire du tout, ni dans la version 2017, ni dans la version 2022.
https://metawatt.fr/scenarios/negawatt-2022
Quand je regarde la source (https://www.negawatt.org/IMG/pdf/scenario-negawatt-2022-rapport-complet-partie5.pdf), pages 11 et 13 je ne vois effectivement plus de nucléaire.
Du coup, la page sur l'analyse d'impact, elle veut dire quoi exactement ? Si on regarde le second graphique, ça indique "production totale de aujourd'hui jusqu'en 2050". Donc c'est du cumulé ? Et c'est vrai aussi pour le premier graphique même si il ne le dit pas ?
# Moui… mais…
Posté par Dring . En réponse au journal Douze facteurs dans ta tronche. Évalué à 8.
Je suis plutôt d’accord avec la vision « le dogme c’est mal ».
Mais c’est quoi qui te gêne avec l’idée du « 1 repo pour 1 app » ?
Et tu ne penses pas que pour les logs, pour une exécution dans un cloud type kubernetes, le point 11 soit également valide ? Dans le principe, on doit généralement considérer qu’on n’a aucun stockage à disposition puisque en cas du destruction du node, tout peut et va disparaître.
# Phoronix
Posté par Dring . En réponse au journal Vie et mort (?) de JPEG-XL. Évalué à 10.
J’aimerais comprendre comment le mec derrière Phoronix, qui signe tous ou pratiquement tous les articles de ce site, fait pour suivre tous ces sujets.
Là il écrit « j’étais tranquillement en train de regarder tous les changements de code dans le code de Chrome quand je suis tombé sur ce commentaire ».
Boudiou ! On a l’impression qu’il fait ça au petit déjeuner avant sa demi-heure quotidienne de LKML. Certes il est journaliste et tout ça est dans son domaine de prédilection, mais j’ai quand même envie de dire « respect ».
[^] # Re: Mauvais côté
Posté par Dring . En réponse au lien Cahier d'idées pour un navigateur écologique. Évalué à 2.
Bien sûr que si les clients doivent s’alléger aussi. C’est pas l’un ou l’autre, c’est les deux.
# Has been?
Posté par Dring . En réponse au journal Quel service choisir pour héberger une liste de diffusion ?. Évalué à 10.
Pour les boomers et les retraités, utilise ton mur facebook.
Pour les milleniums, fais des posts Insta qui renvoie vers des vidéos YouTube.
Pour les morveux, fais une vidéo tiktok - sans texte car de toute façon ils ne savent pas lire.
[^] # Re: Non linéaire ?
Posté par Dring . En réponse au sondage Ton éditeur de vidéo non linéaire favori. Évalué à 4. Dernière modification le 18 octobre 2022 à 12:53.
C'est ma compréhension aussi :