Le fond de la question est : en quoi aurait-il été dommage de la jeter ?
C'est toujours un peu triste de jeter du travail déjà fait, mais vaut-il mieux publier une dépêche moyennement peu pertinente pour éviter de perdre une traduction, ou se dire que tant pis, ça n'a plus vraiment de sens, et l'abandonner ?
C'est de vraies questions et j'ai l'impression que le cœur de la dispute vient du fait que vous n'y apportez pas les mêmes réponses.
C'est assez vrai. Dans le cas de Java, l'effet est renforcé par :
L'historique du langage (fonctionnalités arrivées tard) que certains n'ont toujours pas intégrés (en réalité / dans leurs reproches)
Un langage (et un moteur d'exécution) qui comporte plus de subtilités qu'on pourrait le croire (comme la gestion mémoire), ou dont le fonctionnement change avec le temps (le garbage collector / le compilateur JIT)
Le fait que c'est un langage orienté Entreprise™ avec tout ce que ça implique comme :
Les équipes ultra-morcelées avec des gens qui bossent 3 mois sur un tout petit bout du code
Les projets très longs et très chers donc impossibles à refacto / réécrire
La faiblesse de la communauté open-source et de l'outillage qui peut arriver avec (ne serait-ce que des règles aussi idiotes qu'un formatage du code par défaut)
PHP me donnait plus l'impression de poser problème à cause de failles intrinsèques au langage (PHP 4 était une jolie collection d'incohérences) ; JS plus à cause de sa communauté et de son mode de fonctionnement ultra-éclaté.
PS : les prérequis éditeurs, par contre c'est une vraie plaie. Dédicace à IBM qui vends des logiciels Java qui ne fonctionnent que sur une JVM IBM (J9, maintenant libéré sous le nom OpenJ9 et propriétés de la fondation Eclipse). Mais c'est généralement des limitations arbitraires.
Ca bouffe un tas de ram puisque tu dois fixer un minimum/maximum
Ça consomme la RAM que tu lui demande. Libérer de la RAM, ça veut dire passer le GC, donc c'est consommateur, donc tant qu'on peut éviter, on évite. Pendant très longtemps les JVM ont considéré que ce que tu lui donne en max, ils peuvent le consommer sans problème, Java 12 a justement une évolution pour rendre la RAM libérée au plus vite.
Cela dit, le vrai problème de la gestion de la RAM avec la JVM, c'est les développeurs qui confondent garbage collector avec c'est magique j'ai plus besoin de gérer la RAM, et donc qui développent des programmes qui sont en gros une fuite mémoire géante. Et qui accusent la JVM de leur propre merde ensuite.
ça log comme ça veut et ça ne respecte pas les logrotate
Ça loggue comme tu lui dit de logguer, et j'ai vu des tas de logrotate fonctionner nickel en production sur des JVM (4 à 11). Mais là encore ça implique que le programme à l'origine est un minimum bien conçu.
Ah oui et la tendance naturelle à crasher au moindre pépin, par exemple sur un lag de BDD c'est vraiment génial.
Là encore, ça dépend principalement de comment tu as codé ton application.
En résumé, le problème de Java, c'est pas la JVM. C'est son historique dément de projets abscons, antiques, développés par des générations innombrables de prestataires mal formés et qui n'en on rien à foutre du projet, qu'on ne laisse pas s'intéresser à la façon de bien coder puisqu'il s'agit de faire survivre coute que coute un existant déjà à son dernier souffle. Les « architectes » qui n'ont jamais revu leur façon de faire depuis celles en vigueur dans les très grosses boites des années 1990 y sont aussi pour beaucoup.
Mais c'est bien plus facile d'accuser la JVM que de se remettre en question, je suppose.
même Microsoft qui est une grande union (d'actionnaire, de développeurs…) s'y est cassé les dents avec Windows Mobile arrivé trop tard sur le marché du coup déjà saturé.
J'ai eu l'occasion d'avoir un téléphone sous Windows Mobile 5.0 à l'été 2005, soit avant l'arrivée de l'iPhone et de quasiment tous les smartphones. Microsoft ne s'est pas pété les dents sur le marché du smartphone parce qu'ils sont arrivés trop tard avec Windows Mobile, mais parce qu'ils ont fait une collection hallucinante de mauvais choix :
Ergonomie catastrophique (Windows Mobile avait à peu près la tronche d'un Windows de bureau, sur un téléphone bien plus petit qu'un smartphone actuel)
Stabilité inexistante
Performances horribles
N'a pas pris le virage des smartphones tels qu'ils se sont développés à partir de 2008
etc (dont sans doute plein de choix douteux quant à leur intégration et les applications tierces).
Ils ont fini par redresser le tir et Windows Mobile 8 et surtout 10 n'étaient techniquement pas de mauvais produits, mais c'était beaucoup trop tard… par contre, objectivement ils étaient là avant presque tout le monde !
J'ai déjà répondu au gros du message plus bas, avant que tu ne le postes. Je trouves ça triste de vouloir restreindre l'incroyable richesse des langues mondiales, et de vouloir imposer un système d'écriture qui n'est pas celui de l'incroyable majorité de la population mondiale (pas même du français, à cause des diacritiques).
Cela dit :
on devrait utiliser du utf-16 ou utf-32; où les caractères sont de taille fixe.
PS : tu mélanges un peu tout. Unicode a prévu des classes de caractères. Pour la programmation, il suffit de n'accepter comme identifiants que ce qui est un caractère réel, pas un symbole ou une espace etc.
Je ne m'étonne guère de votre intervention. En postant ici, comme d'habitude, je pensais m'attirer la foudre…Et bingo !
Pourquoi tu as posté alors ? Si tu sais qu'on ne veut pas de ta publicité et que tu n'en retireras rien… contentes-toi de ne pas poster. Ça t'éviteras une perte d'énergie, et de venir chouiner en public en faisant des généralités de ton cas particulier.
Et ce sera infiniment plus agréable pour tout le monde.
Déjà l'honnêteté intellectuelle m'oblige à préciser qu'en réalité,tant qu'on parle de la JVM ICU permet déjà ce genre de chose (en plus complet mais avec une API plus compliquée, et sans garantie quant à la gestion des catégories, cf ci-dessous).
Et quelques précisions pour répondre aux commentaires ci-dessus.
Bien évidemment, ce genre d'outil ne doit servir en aucun cas à forcer du simple ASCII. Unicode est un progrès gigantesque dans un monde où les outils de l'état massacrent encore les noms et prénoms de ses propres citoyens (ceux qui ont une diacritique dans leur nom ou prénom savent à quel point elle est souvent supprimée). Ne nous servons pas de ces possibilités pour régresser, merci.
C'est pour ça qu'il y a des outils pour récupérer des alias et surtout des catégories sur les caractères ; et surtout que les outils de gestion des confusions permettent de gérer des catégories de caractères « de base ». Par exemple pour une application en Français, on voudrait d'autoriser / ne détecter les risques de confusion qu'au sein d'une classe de caractères. Par exemple, une application en français voudrait pouvoir éviter les chaines qui contiennent des caractères que l'on peut confondre avec des caractères latins mais qui n'en sont pas (les caractères latins sont considérés comme légitimes). Une application en russe voudrait elle que ce soit les caractères cyrilliques qui sont légitimes. Je vous renvoie à la doc pour plus de détails1
Aujourd'hui ce qu'il manque à confusables-homoglyphs, c'est l'équivalent des skeleton de ICU, c'est-à-dire une fonctionnalité qui permet d'enregistrer une version « normalisée » d'une chaine de caractères. Cette version n'est pas utilisable à l'affichage, mais permet des comparaisons : deux chaines de même squelette peuvent être confondues. En enregistrant le squelette dans un champ ad hoc, on peut autoriser par exemple des pseudonymes avec n'importe quels caractères, tout en interdisant facilement tout autre pseudonyme homoglyphe.
Enfin, tout l'intérêt des exemples était de montrer que dans certains cas, il n'y a absolument aucun moyen graphique de discerner deux homoglyphes. En réalité l'exemple des noms de domaines était repiqué de la doc d'origine, mais est assez mauvais parce que les navigateurs vont afficher le nom de domaine canonique, donc http://www.xn--faebook-6pf.com/ et http://www.xn--microsft-sbh.com/ – en plus du fait que les utilisateurs font rarement attention à ce qu'il y a dans la barre d'URL.
Celle du projet Python d'origine, j'ai oublié de publier la doc Java… ↩
D'autre part, au-delà du troll sur Java, je serais curieux de voir le concept poussé dans d'autres langages, pour voir si ça fonctionne vraiment au-delà de la théorie.
J'ai testé uniquement avec une JVM OpenJDK 11. Si j'y pense, j'essaierai avec une OpenJ9 11 (anciennement IBM, maintenant fondation Eclipse) – mais ça attendra lundi que le PC sur lequel c'est installé soit réparé.
C'est difficilement accessible à certaines personnes. Pour d'autres souffrant par exemple de trouble de l'attention ça peut être salvateur. Ça peut aussi permettre de suivre un cours ou un sujet juste à l'écoute.
La plupart des cours d'informatique que j'ai eu l'occasion de voir sont par nature très à suivre sans support visuel (le code et son rendu).
Youtube permet d'ajouter des overlay assez facilement et bon nombre de youtubeurs font des retouches post prod.
J'ai fait pas mal de validations de contenus pour feu le Site du Zéro, et quelques-unes pour Zeste de Savoir. Et j'ai moi-même écrit plusieurs tutoriels et articles. Ce qu'il en ressort, c'est mon point de vue sur la relecture par les tiers : si tu aimes le travail propre, tu vas avoir beaucoup de modifications par rapport à la v1. Bien plus que ce que tu peux te permettre pour les overlays (qui restent très pratiques pour les coquilles qui sont passées au travers du filet).
Modifier son prompt c'est du développement ?
C'est assez proche pour que la plupart des remarques s'appliquent.
Maintenant, si tu penses que c'est utile, j'ai quelques pistes pour t'améliorer :
La voix : prépare ton texte, et lis-le autant que possible. Ça évitera les hésitations, les sautes de rythme, etc.
Fais du montage. Ici la première seconde tu finis un réglage. C'est la première seconde, la vidéo n'a pas vraiment commencé, et tu nous montres que tu ne maitrises pas ton format.
La caméra en contre-plongée fait un joli plan sur tes trous de nez, mais je pense qu'on peut faire mieux.
Visiblement tu passes ton temps à regarder un deuxième écran, donc à regarder carrément à côté de la caméra. C'est très perturbant.
Attention aux détails dans le décor, comme le panier de linge (?) en bas à gauche, ou le carton qui déborde au-dessus de ta tête.
Quant au contenu, je n'ai pas d'avis, à cause de ce que je détaille dans le lien.
Bon courage à toi si tu décides de continuer dans cette voie !
Rien à voir, c'est juste que les éditeurs français sont ultraconservateurs et ne veulent surtout pas vendre de ebooks. Certains vendent même les versions électroniques plus chères que les versions papier (surtout quand le livre existe en poche).
Non, mais j'en voyais parler d'utiliser UTC partout : c'est pratique (voire indispensable) pour les programmes, mais inutilisable dans la vie courante.
Ça changerait rien à ta vie, c'est juste qu'au lieu de bosser à 9h30 et de te coucher à minuit heure légale, tu irais bosser à 7h30 et tu irais te coucher à 22h heure légale et solaire… ce qui correspond déjà à ce que tu fais à l'heure solaire.
En fait, l'heure adoptée n'a que peu d'importance, parce que quelle que soit l'heure légale, les habitudes des populations se calent sur le soleil à peu près toujours de la même manière – avec le cas particulier des grandes villes où la saturation des transports conduit à des décalages.
C'est visible et documenté en particulier en France, qui a changé de fuseau horaires plusieurs fois au cours du XXème Siècle. Par exemple, les horaires solaires des institutions n'ont pratiquement pas changé quand la France est passée de UTC0/UTC+1 à UTC+1/UTC+2 : ce sont les horaires légaux qui ont bougés. Typiquement un musée qui ouvre à 10h en hiver ouvrait à 9h en hiver en 1900.
C'est aussi très visible quand on voyage dans un pays qui a un décalage au soleil sensiblement différent de celui de la France. Les horaires en Espagne sont généralement plus tardifs qu'en France métropolitaine ; les horaires en Nouvelle-Calédonie (UTC+11 l'île est centrée sur 165°Est, ce qui est le méridien de référence de ce fuseau) sont décalés vers le matin. Ça donne des horaires d'école du genre « 7h45-11h15 et 13h-15h30 », des gens qui mangent vers midi pile et très peu de bus après 21h.
En fait, c'est juste une habitude à prendre de mettre d'autres chiffres sur ses activités habituelles.
Par contre, si UTC+0 peut sembler pratique à des français métropolitains – qui vivent près du méridien 0, donc sans gros décalage – ce fuseau horaire devient beaucoup moins pratique pour toute personne qui se retrouverait avec un décalage tel que le changement de date surviendrait en pleine journée. Soit probablement la majorité de la population mondiale.
[^] # Re: Alors ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Il y a six mois Linus décidait de changer, a‐t‐il réussi ?. Évalué à 4.
Le fond de la question est : en quoi aurait-il été dommage de la jeter ?
C'est toujours un peu triste de jeter du travail déjà fait, mais vaut-il mieux publier une dépêche moyennement peu pertinente pour éviter de perdre une traduction, ou se dire que tant pis, ça n'a plus vraiment de sens, et l'abandonner ?
C'est de vraies questions et j'ai l'impression que le cœur de la dispute vient du fait que vous n'y apportez pas les mêmes réponses.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java > 1.8
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java XII est dehors. Évalué à 4.
C'est assez vrai. Dans le cas de Java, l'effet est renforcé par :
PHP me donnait plus l'impression de poser problème à cause de failles intrinsèques au langage (PHP 4 était une jolie collection d'incohérences) ; JS plus à cause de sa communauté et de son mode de fonctionnement ultra-éclaté.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java > 1.8
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java XII est dehors. Évalué à 3.
PS : les prérequis éditeurs, par contre c'est une vraie plaie. Dédicace à IBM qui vends des logiciels Java qui ne fonctionnent que sur une JVM IBM (J9, maintenant libéré sous le nom OpenJ9 et propriétés de la fondation Eclipse). Mais c'est généralement des limitations arbitraires.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java > 1.8
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java XII est dehors. Évalué à 10.
Ça consomme la RAM que tu lui demande. Libérer de la RAM, ça veut dire passer le GC, donc c'est consommateur, donc tant qu'on peut éviter, on évite. Pendant très longtemps les JVM ont considéré que ce que tu lui donne en max, ils peuvent le consommer sans problème, Java 12 a justement une évolution pour rendre la RAM libérée au plus vite.
Cela dit, le vrai problème de la gestion de la RAM avec la JVM, c'est les développeurs qui confondent garbage collector avec c'est magique j'ai plus besoin de gérer la RAM, et donc qui développent des programmes qui sont en gros une fuite mémoire géante. Et qui accusent la JVM de leur propre merde ensuite.
Ça loggue comme tu lui dit de logguer, et j'ai vu des tas de logrotate fonctionner nickel en production sur des JVM (4 à 11). Mais là encore ça implique que le programme à l'origine est un minimum bien conçu.
Là encore, ça dépend principalement de comment tu as codé ton application.
En résumé, le problème de Java, c'est pas la JVM. C'est son historique dément de projets abscons, antiques, développés par des générations innombrables de prestataires mal formés et qui n'en on rien à foutre du projet, qu'on ne laisse pas s'intéresser à la façon de bien coder puisqu'il s'agit de faire survivre coute que coute un existant déjà à son dernier souffle. Les « architectes » qui n'ont jamais revu leur façon de faire depuis celles en vigueur dans les très grosses boites des années 1990 y sont aussi pour beaucoup.
Mais c'est bien plus facile d'accuser la JVM que de se remettre en question, je suppose.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Choix facile
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Navigateur web, l'impossible choix. Évalué à 6.
J'ai eu l'occasion d'avoir un téléphone sous Windows Mobile 5.0 à l'été 2005, soit avant l'arrivée de l'iPhone et de quasiment tous les smartphones. Microsoft ne s'est pas pété les dents sur le marché du smartphone parce qu'ils sont arrivés trop tard avec Windows Mobile, mais parce qu'ils ont fait une collection hallucinante de mauvais choix :
Ils ont fini par redresser le tir et Windows Mobile 8 et surtout 10 n'étaient techniquement pas de mauvais produits, mais c'était beaucoup trop tard… par contre, objectivement ils étaient là avant presque tout le monde !
La connaissance libre : https://zestedesavoir.com
# Langues
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Conférence : «Le logiciel libre face à l'informatique» - Richard Stallman - 29/03 - ISTIC Rennes. Évalué à 5.
Pourquoi le résumé et la bio sont en anglais si la conférence est en français ?
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est très bien fait
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien coloriser avec le deep learning des photos noires et blancs. Évalué à 4.
Une photo noir et blanc d'un paysage sur Mars donne des résultats très étonnants (et ma foi assez jolis).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Microsоft.com, Faϲebook.com
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche confusable-homoglyphs : une bibliothèque pour gérer les caractères qui se ressemblent. Évalué à 2. Dernière modification le 19 mars 2019 à 21:56.
J'ai déjà répondu au gros du message plus bas, avant que tu ne le postes. Je trouves ça triste de vouloir restreindre l'incroyable richesse des langues mondiales, et de vouloir imposer un système d'écriture qui n'est pas celui de l'incroyable majorité de la population mondiale (pas même du français, à cause des diacritiques).
Cela dit :
Les caractères UTF-16 n'ont pas une taille fixe (même si ce n'est pas la même gestion qu'avec UTF-8).
PS : tu mélanges un peu tout. Unicode a prévu des classes de caractères. Pour la programmation, il suffit de n'accepter comme identifiants que ce qui est un caractère réel, pas un symbole ou une espace etc.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Mais bien-sur !
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Elphyrecoin : la cryptomonnaie au service de l'opensource. Évalué à 10.
Pourquoi tu as posté alors ? Si tu sais qu'on ne veut pas de ta publicité et que tu n'en retireras rien… contentes-toi de ne pas poster. Ça t'éviteras une perte d'énergie, et de venir chouiner en public en faisant des généralités de ton cas particulier.
Et ce sera infiniment plus agréable pour tout le monde.
La connaissance libre : https://zestedesavoir.com
# Quelques précisions…
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche confusable-homoglyphs : une bibliothèque pour gérer les caractères qui se ressemblent. Évalué à 8. Dernière modification le 15 mars 2019 à 17:24.
Hello,
Déjà l'honnêteté intellectuelle m'oblige à préciser qu'en réalité,tant qu'on parle de la JVM ICU permet déjà ce genre de chose (en plus complet mais avec une API plus compliquée, et sans garantie quant à la gestion des catégories, cf ci-dessous).
Et quelques précisions pour répondre aux commentaires ci-dessus.
Je précise que l'outil fait de la détection multi-caractères :
©et(c)vont être considérés comme pouvant être confondus (dans les deux sens).Bien évidemment, ce genre d'outil ne doit servir en aucun cas à forcer du simple ASCII. Unicode est un progrès gigantesque dans un monde où les outils de l'état massacrent encore les noms et prénoms de ses propres citoyens (ceux qui ont une diacritique dans leur nom ou prénom savent à quel point elle est souvent supprimée). Ne nous servons pas de ces possibilités pour régresser, merci.
C'est pour ça qu'il y a des outils pour récupérer des alias et surtout des catégories sur les caractères ; et surtout que les outils de gestion des confusions permettent de gérer des catégories de caractères « de base ». Par exemple pour une application en Français, on voudrait d'autoriser / ne détecter les risques de confusion qu'au sein d'une classe de caractères. Par exemple, une application en français voudrait pouvoir éviter les chaines qui contiennent des caractères que l'on peut confondre avec des caractères latins mais qui n'en sont pas (les caractères latins sont considérés comme légitimes). Une application en russe voudrait elle que ce soit les caractères cyrilliques qui sont légitimes. Je vous renvoie à la doc pour plus de détails1
Aujourd'hui ce qu'il manque à confusables-homoglyphs, c'est l'équivalent des skeleton de ICU, c'est-à-dire une fonctionnalité qui permet d'enregistrer une version « normalisée » d'une chaine de caractères. Cette version n'est pas utilisable à l'affichage, mais permet des comparaisons : deux chaines de même squelette peuvent être confondues. En enregistrant le squelette dans un champ ad hoc, on peut autoriser par exemple des pseudonymes avec n'importe quels caractères, tout en interdisant facilement tout autre pseudonyme homoglyphe.
Enfin, tout l'intérêt des exemples était de montrer que dans certains cas, il n'y a absolument aucun moyen graphique de discerner deux homoglyphes. En réalité l'exemple des noms de domaines était repiqué de la doc d'origine, mais est assez mauvais parce que les navigateurs vont afficher le nom de domaine canonique, donc http://www.xn--faebook-6pf.com/ et http://www.xn--microsft-sbh.com/ – en plus du fait que les utilisateurs font rarement attention à ce qu'il y a dans la barre d'URL.
Celle du projet Python d'origine, j'ai oublié de publier la doc Java… ↩
La connaissance libre : https://zestedesavoir.com
[^] # Re: Unicode
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Des emojis en SQL ? C'est possible… et on peut aller au-delà !. Évalué à 2.
D'autre part, au-delà du troll sur Java, je serais curieux de voir le concept poussé dans d'autres langages, pour voir si ça fonctionne vraiment au-delà de la théorie.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Unicode
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Des emojis en SQL ? C'est possible… et on peut aller au-delà !. Évalué à 2.
J'ai testé uniquement avec une JVM OpenJDK 11. Si j'y pense, j'essaierai avec une OpenJ9 11 (anciennement IBM, maintenant fondation Eclipse) – mais ça attendra lundi que le PC sur lequel c'est installé soit réparé.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Des soucis classiques
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Ma première vidéo. Évalué à 2.
La plupart des cours d'informatique que j'ai eu l'occasion de voir sont par nature très à suivre sans support visuel (le code et son rendu).
J'ai fait pas mal de validations de contenus pour feu le Site du Zéro, et quelques-unes pour Zeste de Savoir. Et j'ai moi-même écrit plusieurs tutoriels et articles. Ce qu'il en ressort, c'est mon point de vue sur la relecture par les tiers : si tu aimes le travail propre, tu vas avoir beaucoup de modifications par rapport à la v1. Bien plus que ce que tu peux te permettre pour les overlays (qui restent très pratiques pour les coquilles qui sont passées au travers du filet).
C'est assez proche pour que la plupart des remarques s'appliquent.
La connaissance libre : https://zestedesavoir.com
# Des soucis classiques
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Ma première vidéo. Évalué à 7. Dernière modification le 04 mars 2019 à 16:24.
Avant toute chose, voici mon avis détaillé sur ce genre de vidéo dans leur concept même.
Maintenant, si tu penses que c'est utile, j'ai quelques pistes pour t'améliorer :
Quant au contenu, je n'ai pas d'avis, à cause de ce que je détaille dans le lien.
Bon courage à toi si tu décides de continuer dans cette voie !
La connaissance libre : https://zestedesavoir.com
[^] # Re: En effet, mais on parle aussi de libre parfois ici
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Le Guide du Voyageur Galactique a enfin un successeur : Pixel !. Évalué à 3.
Tu oublies le rôle de promoteur dans la vente ; et c'est très souvent ce rôle qui est complètement oublié par les éditeurs aujourd'hui.
Beaucoup d'éditeurs impriment des dizaines de trucs et n'en assurent aucune promotion, forcément ils ne se vendent pas.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Numérique
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Le Guide du Voyageur Galactique a enfin un successeur : Pixel !. Évalué à 7.
Rien à voir, c'est juste que les éditeurs français sont ultraconservateurs et ne veulent surtout pas vendre de ebooks. Certains vendent même les versions électroniques plus chères que les versions papier (surtout quand le livre existe en poche).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Révolution bourgeoise
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Grand débat. Évalué à 7.
Pour les curieux, une série intéressante sur la révolution française, où l'on parle justement des cahiers de doléance et du rapport entre révolution et bourgeoisie.
La connaissance libre : https://zestedesavoir.com
[^] # Re: articles dans Ouest France
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Hacker du dimanche. Évalué à 3.
Mine de rien le franc CFA vaut plus que ce qu'on pourrait croire : 1 000 000 000 XAF/XOF donnent 1 524 490,86 € quand même !
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pas photo
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal [HS] Etes-vous pour rester à l'heure d'été ou à l'heure d'hiver ?. Évalué à 3.
À noter que ton calcul fait la supposition étrange que les horaires d'école resteront les mêmes, que l'heure légale soit UTC ou UTC+2.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pas photo
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal [HS] Etes-vous pour rester à l'heure d'été ou à l'heure d'hiver ?. Évalué à 5.
Et du coup ça devient un problème en été, surtout dans le sud :p
La connaissance libre : https://zestedesavoir.com
[^] # Re: L'heure n'a pas d'importance, les gens vivent en fonction du soleil – et UTC0 n'est pas pratique
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal [HS] Etes-vous pour rester à l'heure d'été ou à l'heure d'hiver ?. Évalué à 4.
Non, mais j'en voyais parler d'utiliser UTC partout : c'est pratique (voire indispensable) pour les programmes, mais inutilisable dans la vie courante.
La connaissance libre : https://zestedesavoir.com
[^] # Re: On est à l'ouest de l'Europe
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal [HS] Etes-vous pour rester à l'heure d'été ou à l'heure d'hiver ?. Évalué à 5.
Les USA ont répondu à cette problématique en traçant des limites de fuseau horaires qui ne suivent pas les limites des états.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pas photo
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal [HS] Etes-vous pour rester à l'heure d'été ou à l'heure d'hiver ?. Évalué à 5.
Ça a déjà été fait plusieurs fois au XXème siècle. Ce serait lourd, mais très loin d'être impossible.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pas photo
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal [HS] Etes-vous pour rester à l'heure d'été ou à l'heure d'hiver ?. Évalué à 7.
Ça changerait rien à ta vie, c'est juste qu'au lieu de bosser à 9h30 et de te coucher à minuit heure légale, tu irais bosser à 7h30 et tu irais te coucher à 22h heure légale et solaire… ce qui correspond déjà à ce que tu fais à l'heure solaire.
La connaissance libre : https://zestedesavoir.com
# L'heure n'a pas d'importance, les gens vivent en fonction du soleil – et UTC0 n'est pas pratique
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal [HS] Etes-vous pour rester à l'heure d'été ou à l'heure d'hiver ?. Évalué à 8.
En fait, l'heure adoptée n'a que peu d'importance, parce que quelle que soit l'heure légale, les habitudes des populations se calent sur le soleil à peu près toujours de la même manière – avec le cas particulier des grandes villes où la saturation des transports conduit à des décalages.
C'est visible et documenté en particulier en France, qui a changé de fuseau horaires plusieurs fois au cours du XXème Siècle. Par exemple, les horaires solaires des institutions n'ont pratiquement pas changé quand la France est passée de UTC0/UTC+1 à UTC+1/UTC+2 : ce sont les horaires légaux qui ont bougés. Typiquement un musée qui ouvre à 10h en hiver ouvrait à 9h en hiver en 1900.
C'est aussi très visible quand on voyage dans un pays qui a un décalage au soleil sensiblement différent de celui de la France. Les horaires en Espagne sont généralement plus tardifs qu'en France métropolitaine ; les horaires en Nouvelle-Calédonie (UTC+11 l'île est centrée sur 165°Est, ce qui est le méridien de référence de ce fuseau) sont décalés vers le matin. Ça donne des horaires d'école du genre « 7h45-11h15 et 13h-15h30 », des gens qui mangent vers midi pile et très peu de bus après 21h.
En fait, c'est juste une habitude à prendre de mettre d'autres chiffres sur ses activités habituelles.
Par contre, si UTC+0 peut sembler pratique à des français métropolitains – qui vivent près du méridien 0, donc sans gros décalage – ce fuseau horaire devient beaucoup moins pratique pour toute personne qui se retrouverait avec un décalage tel que le changement de date surviendrait en pleine journée. Soit probablement la majorité de la population mondiale.
La connaissance libre : https://zestedesavoir.com