Sufflope a écrit 3182 commentaires

Je ne sais pas par quelle magie mais ça a l'air de pas si mal marcher que ça, la capture d'écran sous Wayland :

Mieux que le restart de gnome-shell, en tout cas.

Ceci dit si j'en crois un ami ayant vécu en Corée du Sud au début des années 2000 (donc pas le tiers monde), 5 à 10€ c'est effectivement ce que coûtent des lunettes, c'est pas déconnant donc.

Compiz c'est plutôt quelques effets 3D ajoutés au paradigme existant (le bureau à la Windows 95). Il a l'air de plutôt parler de trucs à la Looking Glass, et même d'aller plus loin.

Si non, l'offre et la demande ça marche aussi dans ce sens: il y a peu de demande, alors l'offre sera plus cher.

Euh n'importe quoi. C'est bien connu, ce qui a du mal à se vendre, on l'augmente… C'est l'absence d'économies d'échelle sur leur petite production qui fait exploser les prix, pas une espèce d'anti-loi de l'offre et de la demande inversée à la anti-matière.

a une justice suffisamment indépendante pour limiter l'arbitraire de l'exécutif face aux opposants

Heureusement la légalisation de l'état d'urgence va combler cette faille.

Et c'est surtout une chose due.

Tu peux utiliser un Android sans compte Google en le synchronisant sur un fournisseur Cal/CardDav tiers et en utilisant f-droid par exemple.

Bon faut être honnête ça fait pas exactement pareil (ça crée le dossier mais s'il existait déjà ça renvoie false). Là c'est bon :

File f = new File(rep); f.isDirectory() || f.mkdir()

ex : [ -d $REP ] || mkdir $REP # l'équivalent java (idem python / perl) doit prendre un peu plus de lignes :)

new java.io.File(rep).mkdir()

De rien.

P.S. : il se passe quoi avec ton code si REP contient un espace ?

Pendant des années j'ai écrit des .properties en UTF-8 avec Eclipse, donc oui je le mets dans le lot des outils qui le permettent. Je n'utilise pas vraiment N++ ni vi ni emacs mais je doute qu'ils refusent d'éditer des .properties en unicode.

Les fichiers *.properties pourront enfin être écrits en UTF-8. Ces fichiers, souvent utilisés pour l'internationalisation, étaient limités à ISO-8859-1…

En réalité avec des outils un tant soit peu modernes, on peut les écrire en UTF-8 depuis longtemps. Mais c'était une entorse à la norme JEE sans garantie de fonctionnement dans tous les conteneurs, certes.

Maintenir une version d'OpenSSH à jour et sécurisée sur un serveur distant était une tâche au-dessus de mes compétences en administration système,

apt install openssh-server ou équivalent c'était trop compliqué, donc pour faire plus simple je réimplémente SSH ? Si la page Wikipedia pour NIH avait besoin d'une illustration, elle est servie.

Je rebondis sur mon (y a même des chances que ça ne compile juste pas) avec un exemple.

Supposons que j'ai sur master cette méthode en Groovy pour récupérer un utilisateur dans mon appli Grails, qui filtre les utilisateurs blacklistés (on passera sur la propreté d'utiliser des null, de ne pas filtrer directement en base, etc., hein, c'est un exemple) :

def getUser(String login) {
  def user = User.findByLogin(login)
  if (user.blacklisted) return null
  return user
}

Dans la branche A le développeur gentil décide que le blacklist c'est trop méchant et retire ce filtre :

def getUser(String login) {
  def user = User.findByLogin(login)
  return user
}

Plus tard, dans la branche B le développeur méchant pense que le blacklist c'est cool et qu'en plus un type qui ne s'est pas connecté depuis 1 mois c'est louche :

def getUser(String login) {
  def user = User.findByLogin(login)
  if (user.blacklisted) return null
  else if (user.lastAccess < DateTime.now.minusMonths(1)) return null
  return user
}

Qu'est-ce que pijul va faire au merge ? S'il applique les patchs successivement le résultat ne compilera même pas avec un else orphelin :

def getUser(String login) {
  def user = User.findByLogin(login)
  else if (user.lastAccess < DateTime.now.minusMonths(1)) return null
  return user
}

Toute autre combinaison valide syntaxiquement (retirer les deux test, garder les deux) est indécidable sans les specs de l'appli. Ainsi que toute modification (genre retirer le premier filtre mais garder celui sur la date en retirant le else, comment tu sais que c'est ce qu'on veut finalement ? Et pijul ne parle pas le Groovy à priori).

À moins que j'ai vraiment loupé un truc, seule l'attitude de git, s'arrêter et te dire t'es gentil tu corriges tes conneries est valide.

C'est marrant comme il suffit de parler d'un concept mathématique relativement avancé en termes un tant soit peu profanes pour t'invoquer. Y a sûrement une nouvelle tradition de magie à la Ouija à monter.

Je sais d'avance que la suite de cette conversation sera, en réponse, un autre pavé encore plus indigeste pour moi, que je ne comprendrai carrément pas, car j'ai arrêté les maths suffisamment tôt pour ma satisfaction professionnelle vu que j'aime mon travail, mais trop tôt par rapport à la maitrise d'icelles que j'aimerais avoir, mais bon je me lance quand même.

pijul aussi gère, à sa façon, un graphe orienté d'états successifs

Oui alors c'est sûr, si tout le monde appelle dans son cas "état" ce qu'il stocke dans un sommet, on gère tous des états. Git stocke en premier lieu des "états"-"sommets" qui représentent concrètement et trivialement le contenu brut du dépôt aux instants T(x), et ajoute par dessus un graphe de relations bête et méchant. J'ai l'impression que pijul travaille dans l'autre sens en ayant comme citoyen de première classe les arêtes avec le patch comme contenu, et en déduit des sommets-"état du dépôt".

un dépôt c'est une catégorie, c'est-à-dire un graphe orienté qui vérifie certaines propriétés.

Du peu que je sais j'ai l'impression que le c'est-à-dire est à l'envers. Je peux envisager de voir un graphe orienté comme une catégorie, en tant que suite de morphismes dans le même groupe (transformation de fichiers) à chaque fois, mais à l'inverse, voire toute catégorie comme un graphe orienté, j'ai plus de mal, puisque dans une catégorie par définition les morphismes de groupe n'ont à priori pas les mêmes ensembles de définition et d'image ? Ou alors un graphe peut avoir des sommets "fichiers" et des sommets "bananes" si une des arêtes est un morphisme de groupe partant de l'ensemble "fichiers" et arrivant dans l'ensemble "banane", ce qui, convenons-en, ne sera que peu exploitable comme gestionnaire de sources.

Les sommets du graphes sont des « fichiers » et les arcs des patchs : si il y a un arcs entre deux sommets alors la cible est le résultat du patch appliqué à la source.

Si par arc tu veux parler de ce que j'appellerais arête, alors à vérifier mais dans git les sommets c'est pareil (et c'est pas que "des fichiers", c'est "tous les fichiers du dépôt à l'instant T") par contre les arcs ne sont pas valués comme semblent être ceux de pijul, ils ne représentent que la relation "tel commit a tel ascendant dans le graphe". La sortie de git diff par exemple (dans mon souvenir ; si je me goure, j'ai perdu toute crédibilité :-)) n'est pas l'affichage des "patchs" contenus dans les arêtes comme dans pijul, mais est reconstruite en comparant les deux instantanés du dépôt comparés.

En écrivant ça j'ai l'intuition de retrouver ce pourquoi git est si plaisant à utiliser (surtout comparé à SVN qui était dominant à l'époque, il est vrai). Faire un "rebase" en git (prendre un bout de graphe et le déplacer) est extrêmement efficace (il ne déplace que des relations) mais peut effectivement créer des changements autres que ceux "contenus" dans les commits (même si pour rappel un commit ne contient pas de changement mais décrit un nouvel état complet) d'où conflits à résoudre. Sauf que je ne vois pas comment pijul peut être magiquement mieux. Si pijul a stocké "alors là tu changes la ligne 3 du fichier 'foo' de 'bar' vers 'baz'" comme patch, par quelle magie, lorsque je le rebase sur un nouveau sommet où précédemment la dite ligne 3 a été modifiée de 'bar' vers 'boo', il recolle les morceaux ? A part en disant "oh merde je m'en fous je colle 'baz' puisque de toute façon on voulait 'baz'". Ou alors en disant "euh au secours conflit !".
Exactement comme git en fait.

A ce propos je rebondis sur ta première image, c'est précisément le même biais que dans le lien que je critiquais. Vous prenez tous les deux le cas "simple" où la ligne changée dans les deux branches est la même au départ. C'est "simple" pour un humain parce que c'est "la même" visuellement et on se dit "pffff git est con", mais :

• il ne peut pas déterminer que fonctionnellement c'est la même (si dans une branche je change 'bar' en 'boo' puis re en 'bar', c'est toujours la même ? Par quelle règle non écrite qui assure que ce n'est pas une coïncidence ?
• et donc comment votre outil magique résout le problème si malheureusement je sors de votre exemple contrit et je modifie la ligne des deux côtés ?

Ta deuxième image est carrément malhonnête. Tu ajoutes un original qu'il n'y avait pas et qui comme par hasard renforce l'effet visuel de "j'ai juste ajouté une ligne" (sauf que dans la réalité ce n'est qu'un cas particulier simple pour un humain qui comprend le fonctionnel des sources). Si toi et ta femme aviez changé "work" pour une ligne différente chacun de votre côté ?

Par ailleurs le merge final (ainsi que sa généralisation dans la 3ème image) est simplement un merge déterministe, ce qui :

• est parfaitement possible avec git en choisissant une stratégie de merge déterministe
• ne fonctionne pas en réalité : d'accord tu as résolu le merge technique, mais qui te dit que le code fait ce que tu veux (y a même des chances que ça ne compile juste pas) ? Si tu as la réponse, félicitations, tu as trouvé le programme qui prouve tous les autres programmes, tu vas être maître du monde.

Qu'est-ce que l'on entend par inattendu ? Idéalement il faut lire le blog, sinon ce lien donne un explication visuelle.

On comprend bien à la lecture que le mec n'aime pas git, mais bon au risque de passer pour insane à ses yeux ça ne me choque pas. Je m'avance beaucoup sur la maitrise de la chose, mais git ne gère pas des patchs mais un graphe orienté d'états successifs. Son exemple visuel montre clairement qu'il ne construit pas le même graphe dans les deux scénarios, ça ne me choque donc pas que l'état final puisse différer dans un cas extrêmement capillotracté.

C'est vrai que la Syrie c'est pas forcément un super exemple de point fixe en ce moment. Ceci dit, deux points :

• la Syrie n'est-elle pas plus représentative de la moyenne mondiale que la Belgique ou autre pays très riche ?
• même en prenant en exemple la Belgique, ça reste un quart de sa consommation, et un quart de la consommation énergétique d'un pays ultra favorisé juste pour calculer quelques nombres premiers pour acheter de la beuh tranquille, est-ce raisonnable ? Cela passe-t-il à l'échelle ?

ce qui est du même ordre de grandeur que la puissance d'un réacteur nucléaire (qui est un peu moins de 1GW, si j'en crois wikipedia).

C'est vrai que 19,16 TWh par an n'est pas forcément très parlant, mais l'article que je lie donne des ordres de grandeur. L'un, que je n'ai pas repris, est l'ordre de grandeur d'une centrale nucléaire (bravo, ton calcul est donc correct) ; l'autre, que j'ai mis, est la consommation d'un pays de 18M habitants tel que la Syrie. Tout ça pour les BTC qui pour rappel ne servent à l'heure actuelle qu'à quelques geeks à acheter des pizzas ou des noms de domaines chez un registrar qui veut se la jouer cool, et aux ransomwares à faire leur business. Puisque tu es chaud du calcul, ça donnerait quoi comme dépense énergétique pour gérer mettons 10% des échanges mondiaux ?

Alors, l'aspect calorique dans l'atmosphère, ça c'est complètement négligeable.

Au temps pour moi, tu as raison, c'est pas ce que j'aurais du soulever. Donc : les cents PW fournis par le soleil le sont "gratuitement" du point de vue composition de l'atmosphère. Combien de tonnes de CO2 rejetés par les 19,16 TWh par an de fermes chinoises alimentées au charbon ?

Je me demandais justement si le coût global, indirect, de la monnaie papier était si faible que ça. Il y a la sécurisation de son transport par exemple.

J'aillais répondre "au moins ça donne du boulot aux convoyeurs et ça participe à faire vivre la société". Mais en fait fabriquer des CPU pour miner du BTC ça fait vivre des chinois aussi, donc… Ceci dit je subodore que le BTC gâche réellement plus que le transport de billets. Mes impressions :

• le convoyage de biftons ne consomme pas principalement des terres rares, contrairement à la fabrication de CPU
• l'argent utilisé va dans la poche de convoyeurs nombreux et pas trop payés, qui réinvestiront leur paie dans l'économie locale, et pas dans la poche de quelques patrons d'usine géantes de semiconducteurs
• si j'en crois http://www.tomshardware.fr/articles/cryptomonnaie-minage-consommation-ecologie,1-64678.html le minage de Bitcoin et d'Ehtereum, les deux principales monnaies virtuelles, ne demande rien moins que 19,16 TWh par an. 19 160 milliards de watts-heures par an. Soit autant qu'un pays de 18 millions d'habitants comme la Syrie. Et ça, ça part à 90% dans l'atmosphère en dégagement calorique en pure perte, pour 0,000001% des échanges commerciaux mondiaux. S'il fallait passer à même 1% du commerce mondial en BTC on consommerait sûrement plus que toute la population humaine réunie

Il a d'autres qualités, ou d'autres utilisations que "au moins il bougera pas" aux qualités que tu as citées. Par exemple en électronique.

Si tu as la valeur de 10 BTC (on arrondi à 25'000€) tu peux demander à une banque de te "prêter" 100 BTC (250'000€) à un tarif au moment T.

Sauf que c'est faisable en € car n'ayant aucune existence autre qu'une ligne d'écriture dans une invention humaine. En BTC c'est impossible, à moins que ta banque ne sache générer des BTC à la volée, auquel cas elle aura mieux à faire que s'occuper de toi. Si des banques font des "prêts de BTC" ça ne peut être que des prêts de BTC qu'elle possède déjà (fonds propres) soit des prêts d'€/$/… avec marqué leur valeur en BTC sur la plaquette.

Bah vu que ce sont des nombres avec des propriétés spéciales, autant que tu peux avoir physiquement des "non-lingots d'or".

Non justement, pour l'arrondi "classique", mathématique, oui c'est le fait que transformer x.0 en x soit également un arrondi, avec une perte d'information, qui amène à arrondir .5 à l'excès, comme ça on a autant de cas d'excès (5 / 6 / 7 / 8 / 9) que de défauts (0 / 1 / 2 / 3 / 4), mais dans la perspective "tenir des comptes justes" non, puisqu'en arrondissant .1 à la baisse tu "oublies" 0,1, mais le .9 arrondi à la hausse consomme 0,1 donc ça s'équilibre ; mais le .5 arrondi à la hausse consomme 0,5 tandis que le .0 arrondi n'oublie rien, donc pas de compensation. D'où cette règle qui permet de répartir les .5 en deux camps qui vont se compenser les uns les autres.

Premièrement, dit comme ça c'est idiot, 200m de dénivelé, si c'est sur 1km de distance c'est pas rien ; ensuite, tout le monde n'a pas un cœur de bœuf.

Cette incertitude sur le calcul des congés est un frein manifeste à l'embauche. Imaginez, un patron de PME peut du jour au lendemain devoir offrir presque un jour de congé à un salarié ! Nul doute que La République en Marche s'attachera à reformer cet archaisme pour redynamiser le marché de l'emploi.

Même si on se dit que le ton ne va pas, c'est quand même fou de voir que Zenitram est à -7. Apparemment, sur le sujet des parts de marché globales de Linux, "sur http://libregamesinitiatives.tuxfamily.org/ je suis passé de 5 à 95%" a au moins une once de pertinence. Intéressant.