barmic 🦦 a écrit 5815 commentaires

Accessoirement on sait ajouter des Celsius à des Kelvin si l’addition fait sens.

Il faut une étape en plus ne serais-ce que pour affirmer l'unité de ton résultat.

En Bulgarie, quel fut le lendemain du 31 mars 1916 ?

Comme le montre ta réponse ce n'est même pas une question de calendrier. Seul tzdata référence ce genre de choses. Il faut avoir une notion géographique précise pour pouvoir faire ce genre de manipulation, ce n'est pas tout EET qui a fais ce changement. Je suis curieux parce que je n'arrive pas à faire faire la déduction à date.

TZ=':Europe/Sofia' date -d 'March 31 1916 +1 days'

me donne le premier avril et pas le 4… mais je l'ai du premier coup en java ! ZonedDateTime.parse("1916-03-31T00:00:00+02:00[Europe/Sofia]").plusDays(1) (j'aime vraiment beaucoup la bibliothèque de dates de java).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

au moins le saut du calendrier julien au grégorien

Les changements de calendrier c'est encore autre chose. Tu n'ajoute pas une mesure d'un calendrier à un autre, ça reviens à ajouter des °C et des °K.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

date à la seconde près - date à la seconde près 1h avant = 3600 s ?

C'est vrai en POSIX qui décrit l'heure comme étant 3600s et le jour comme 86400s (et bien sûr les minutes comme étant 60s). D'ailleurs la commande date ne sait pas lire 2016-12-31T23:59:60UTC.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Le temps c'est vraiment compliqué et les bibliothèques vraiment bien faites ça ne court pas les rues.

J'ai par exemple vu des bugs arriver au changement d'année alors que ce n'est pas un cas bizarre. Il avait même était testé sur le changement d'année. Mais qui pense que pour toute date tu peux retrouver son année et l'année de sa semaine et que ça peut ne pas correspondre (quand l'année ne commence pas un lundi) ? Et tester ça en 2017 quand comme ce fut le cas cette année le premier janvier tombe un lundi ?

Je trouve la bibliothèque des dates de java excellente (elle a de quoi représenter à peu près tout ce dont tu peux avoir besoin), mais j'ai toujours un doute quant à la manière de faire pour changer une timezone. Il m'arrive de vouloir prendre le premier janvier 1970 00:00 UTC et de vouloir juste remplacer la timezone (donc être toujours à 00:00) ou de vouloir le traduire avec une autre timezone et donc potentiellement tout changer. Les deux sont possibles, mais ça n'est pas intuitif à utiliser.

Résonner avec des timezone du type Europe/Paris plutôt qu'en offset n'est pas non plus intuitif.

C'est un réel savoir de manipuler les dates et aujourd'hui ça s'apprend beaucoup sur le tas.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Mais faut arrêter les généralités abusives c'est encore moins écologique.

Mais note que tous les ordinateurs de particulier ont déjà quelques compilateurs.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je regarde votre conversation depuis quelques jours.

Bref, pas d'accord avec toi, pas grave, mais pas d'accord qu'on crache sur suckless uniquement parce qu'ils ont une vision radicale des choses, et un ton urticant.

Je trouve que c'est mettre beaucoup de valeur a un truc qui n'en a pas. Ils décrivent ce qu'ils apprécient dans leur philosophie. Ils ne viennent chercher des noises à personne, ils ne cherchent pas à changer le monde, ils veulent surtout ne pas être embêté dans le lieu qu'ils construisent. Tu trouvera des dizaines de projets être bien plus énervés dans leur vision du logiciel (ne serais-ce que le fait d'être libre ou pas) et ayant une réelle volonté que leur vision se répande sans que ça ne choque personne.

Et ça fonctionne sans soucis d'utilisabilité.

Je ne suis pas d'accord. Quand une partie des fonctionnalités des logiciels sont décrites par « met à jour le code et recompile » ou « applique ce patch et recompile » tu ne peux pas écarter ça de l'utilisabilité. Ce n'est pas grave en soit leur logiciel ne sont pas fait pour tout le monde, c'est le cas de pleins de logiciels ailleurs et dans leur petit microcosme ils ne veulent pas s'embêter avec. Ce n'est pas bien grave d'autant qu'il existe un tas d'alternatives. Le fais qu'un énorme paquet de logiciels sans en avoir conscience ne sont pas accessibles est un problème bien plus important.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il a de bon argument par rapport à bash ?

Le principal pour moi c'est quand tu commence à faire des manipulations de variables un peu sophistiquées.

file='image.PNG'

if [[ ${(L)file##*.} == 'png' ]]; then
    #…
fi

Ne fonctionne pas en bash parce que tu peux faire ${(L)file},
tu peux faire ${file##*.}, mais tu ne peux pas combiner les 2 en une fois.

Ensuite il y a évidement les modules de zsh qui sont un peu fou où tu a par exemple un client ftp disponible.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je finis sur deux points car je sais qu’on peut/va me les opposer

Tu prend perl il aura le même coût de maintenance, mais n’exécutera aucun fork. Si le coût d'un fork est aussi primordial il ne faut pas utiliser de script shell. Le plus beau pansement que tu aura ne servira à rien sur une jambe de bois. Si comme tu le dis quelque soit le coût du fork tu va fait un million de fois, tu as déjà ton grep qui fork un million de fois. Pire en shell posix tu n'es pas sûr que [ soit un builtin, ça peut très bien utiliser /usr/bin/[.

Vraiment si le coût du fork t'es insupportable, rend-toi service, apprend perl. Tu ne sera pas dépaysé et si le coût des fork est effectivement sensible ça va être le jour et la nuit.

Pas d'« architecture logiciel » différente de ce que tu fais déjà, pas de compilation à gérer, obtenir le mode strict se fait avec une simple ligne en début de fichier use strict;, tout en gardant une grande facilité de fork pour utiliser un programme particulier,… et évidement perl et LA rolce des expressions régulières.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu as vraiment besoin d'une définition de simple?

Tu entends par simple le faible nombre de caractères différents ? Parce que la manière de l'utiliser où chacun ajoute ses diacritiques, où on multiplie les façons d'écrire le même phonèmes, où chaque langue choisi sa manière de prononcer la même écriture, où l'on se sent obligé de faire des ligatures pour améliorer la lecture ainsi qu'une demi douzaine d'espace différentes,… Je pense qu'on est plus dans le simpliste.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Que je sache il y a le hangul qui fait l'unanimité :

• les peuples qui l'ont adopté ne le regrettent pas
• les scientifiques qui étudient les systèmes d'écriture lui trouvent beaucoup de qualités (en particulier il n'y a pas d'écart entre ce qui est écrit et prononcé)
• il n'est pas particulièrement relié à une langue et est en mesure de représenter de manière exacte bien plus de langues¹. Tout le monde l'utilise de la même façon
• il s'adapte très bien par exemple aux usages numériques : la plupart des claviers virtuels n'ont besoin que de quelques touches, l'absence d’ambiguïté simplifie le text2speech et le speech2text,…

Mais oui ce n'est pas ton système d'écriture donc il doit être moins bien, c'est ça ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Et pourquoi "-8"?

-9

Pouvez expliquer en quoi mon intervention dérange ?

Parce qu'elle rebondi sur une partie anecdotique qui n'était pas le propos de mon commentaire c'est à dire ce que fait F5 et pourquoi.

Vous êtes contents qu'il y ait 99% de probabilités que nous soyons en guerre contre poutine dans moins de cinq ans parce que nos décideurs ont eu la trouille de s'opposer à lui quand il en était encore temps ?

Tu aurais était plus content qu'on soit en guerre il y a 10 ans ? Il est vraiment facile de juger les actes passés en ayant toutes les cartes en main (ce que l'on a pas encore). Savoir quand est-ce qu'il est moins pire de déclencher une guerre (ou à minima des hostilités) n'est pas une science.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ne pas avoir de solution ne devrait pas rendre tabou l’évocation des problèmes.

Ça dépend de ce qui est considéré comme problème. Si c'est le design d'UTF8, il faut commencer par aller voir les autres unicodes par exemple. Si c'est la diversité de la culture dans le monde (ce qui a l'air d'être le cas quand la solution imaginée consiste à éradiquer tout système d'écriture autre que le sien), alors on est pas d'accord sur la définition du problème.

il me semble que les problématiques écologiques soulevées par devnewton le soient à titre humoristique.

Humour ne veut pas dire qu'il n'y a pas de propos.

En ce qui me concerne, je songe surtout aux problèmes d’attaques informatiques permises par la versatilité (bien au sens Français ici) de cette convention.

Et des contre-mesures sont construites en ce sens.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est rigolo cette manie de porter doom sur les plateformes les plus farfelues !

On a du mal à imaginer le succès de doom à l'époque. Il me semble qu'il était plus vendu que windows (à une époque où il n'était pas dispo sur windows). Gabe Newel (qui deviendra plus tard monsieur Valve, Half Life, Steam,… l'homme qui ne sait pas compter jusqu'à 3) fera le portage sur Windows et ça donnera une pub comme on en voit rarement (lien youtube - l'image est dégueulasse mais c'est vieux). La relative simplicité de portage et un effet boule de neige et paf c'est devenu une sorte d'hello world.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Il me semblait que vue.js et reactjs fonctionne de la même façon.

JSX n'est pas utilisé par vue. Ce dernier met tout dans le même fichier, mais de manière un peu plus séparé :

<script setup>
import { ref } from 'vue'

// A "ref" is a reactive data source that stores a value.
// Technically, we don't need to wrap the string with ref()
// in order to display it, but we will see in the next
// example why it is needed if we ever intend to change
// the value.
const message = ref('Hello World!')
</script>

<template>
  <h1>{{ message }}</h1>
</template>

La façon jsx de mélanger la vue et le code se rapproche probablement plus d'elm :

import Html exposing (..)


main =
  div []
    [ h1 [] [ text "My Grocery List" ]
    , ul []
        [ li [] [ text "Black Beans" ]
        , li [] [ text "Limes" ]
        , li [] [ text "Chili Powder" ]
        , li [] [ text "Quinoa" ]
        ]
    ]

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ça dépend de ce que tu entends par fonctionnel. KSQL n'apporte probablement rien de plus que pg, mais il le fait au dessus de topic kafka. FondationDB, HBase ou Cassandra font moins que pg fonctionnellement, mais le font des Eio de données en multidatacenter. Redis fait moins que pg mais il le fait entièrement en mémoire. Tu peu réécrire tes requêtes Warp10 avec le SQL de pg, mais une partie de la valeur de ce dernier c'est justement warpscript.

Je dis pas que toutes sont utiles, mais que ce qui peu paraître être des détails que ces bases montrent leur valeur et que croire que pg aussi bien soit-elle les englobe toutes c'est probablement n'avoir jamais eu des besoins trop spécifiques.

Les choix structurels des bases a un impact sur leurs propriétés et leur utilisation. Dire que pg fait tout c'est autant du bullshit que cette surrealdb qui tente de faire croire qu'elle est capable de tout.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Là où c’est amusant, c’est que XML a justement comme avantage de pouvoir être traité, validé, filtré et transformé au fil de l’eau, sans tout monter en mémoire. Même si avec les capacités de traitement modernes, c’est un avantage qui n’a plus un intérêt énorme (en particulier, ça ne compense plus sa difficulté de lecture pour un humain et sa verbosité dans la plupart des cas).

Je trouve ça encore très utiles pas forcément pour éviter le poids en mémoire mais pour traiter la donnée en flux.

XML est plus complexe que JSON, mais par rapport à JSON + json schema ou json5 mais alors il n'y a pas de validation de schémas ou JSONnet ou… JSON n'est pas simple, il est simpliste et beaucoup d'usages doivent finalement trouver un moyen de faire quelque chose en plus de manière plus ou moins ésotérique

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

yq

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ce dont il parle c'est de regarder la facturation. D'une manière ou d'une autre les compteurs sont relevés périodiquement où qu'ils soient.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Moi je vois pas mal d'overengenering et je ne trouve pas que ce soit un sujet véritablement simple. Entre faire le changement minimal ad hoc et prévoir un avenir nécessairement incertain hors de cas évident c'est uniquement la réussite future qui détermine si on a trop, pas assez ou juste suffisamment réfléchis.

Par contre je trouve qu'il faut savoir de grossir un logiciel. Des parties peuvent (ou non) avoir étaient très utile à une époque, mais il faut savoir se reposer la question de temps en temps et dire que bon 60% des cas d'utilisation n'existent plus il faut rationaliser. Je n'ai pas eu le cas de logiciels publique où on te gueule systématiquement dessus si tu le fait comme Firefox (tout en lui reprochant d'être gros, il lui est aussi reproché le retrait de fonctionnalité les rares fois où ça arrive).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Mais en théorie le principe de simplicité devrait rendre tout ça relativement abordable, au moins pour les gens qui ont des notions de programmation.

Uniquement, vraiment, uniquement. La plupart de leur logiciel se configure dans les sources.

Il ne faut vraiment pas voir le projet autrement que comme un petit club qui fait sont truc dans son coin sans chercher conquérir le monde ou autre. Ils veulent développer à leur façon sans qu'on vienne les embêter avec une hypothétique « madame Michu ».

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

On ne se comprends définitivement pas. Un peu de code sera plus clair :

#!/bin/sh

python3 - <<EOF
import re

string = 'This is a string'
pattern = '^[A-Z]'

found = re.match(pattern, string)

if found:
    print("The input value is started with the capital letter")
else:
    print("You have to type string start with the capital letter")
EOF

Je décrivais plus haut le shell come :

1. tu as le language qui est pareil queue pour tout autre langage
2. tu as les binutils globalement qui sont la bibliothèque standard du langage
3. tu as les autres exécutables qui sont des bibliothèques autres comme tu as des bibliothèque dans tous les langages
4. tu as dans tous les langages ou presque la possibilité d'écrire un programme dans un autre langage et de l'executer comme dans mon exemple le shell écris du python et l'execute

Ce dernier point, bien que très utile, n'est pas intéressant dans le cadre d'une comparaison de langages tel qu'on le discutait à la base.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Jamais essayé, je ne peux pas dire.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Oui j’ai vu ça, il y a même un code couleur pour les mécanismes et ces paramètres je crois. C’est un domaine très riche, dont la disposition, par exemple n’est qu’un des aspect.

Maintenant tu as des mécanismes dis analogiques, tu n'a pas de barrière de retour avant de pouvoir réactiver la touche. Dis autrement quand tu as activé une touche, pour la réactiver tu n'a pas à la faire véritablement remonter le moindre relâchement permettra de la réactiver. Ça ne sert que dans le jeu vidéo. Comme le fais de pouvoir appuyer sur plus de 3 touches à la fois, utile par exemple pour jouer à 2 sur un même clavier

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Et je ne suis pas d'accord. Ce n'est qu'une question de goût. C'est une préférence en programmation j'utilise par exemple moins les chiffres (qui hors du 1 et du 0 sont peu utile) que pas mal de caractères comme _-(). Parler des problèmes de raccourcis quand il y a 5 lettres de différentes entre les 2 dispositions c'est ridicule.

Les 2 n'ont pas d'avantage intrinsèque objectifs et ce n'est pas bien grave le meilleur layout c'est celui qui convient à l'utilisateur pas celui qui est réputé le meilleur du monde et au delà.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C’est l’usage de l’azerty qui est une moche habitude que l’on s’impose. Il y a plein de pays, francophones[1] ou pas[2], où l’on écrit en français (ou dans une autre langue latine posant les mêmes soucis de diacritiques[3] et ligatures ou autres symboles) sans devoir se farcir l’inefficacité de l’azerty.

Parler de l'inefficacité de l'azerty pour mettre en avant le qwerty c'est l’hôpital qui se fou de la charité. Ce n'est que l'habitude et les goûts qui fais en préférer sur l'autre. Si on veut parler d'efficacité c'est dvorak et bépo qu'il faut aller regarder (je viens de remarquer que je n'ai aucune idée de commenter écrire Dvořák avec une disposition dvorak).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll