🚲 Tanguy Ortolo a écrit 12720 commentaires

Ça n'a rien à voir avec la norme du connecteur, ça.

Évidemment, il me vient encore des remarques.

J'apprécie beaucoup le fait que l'Union européenne puisse faire plier Apple, et imposer un changement qui sera vraisemblablement mondial. À moins qu'ils ne choisissent de faire une version européenne de leurs appareils, avec un port USB-C, et une version pour le reste du monde, avec un port Lightning, mais je ne les crois tout de même pas si stupides.

Je ne doute pas que certains fanboys ne râlent parce que Lightning, c'était vachement mieux. Sauf qu'en fait non, techniquement, ça avait peut-être certains avantages, je ne sais pas trop, mais ça avait un désavantage énorme : c'était conçu comme un connecteur propriétaire, breveté, avec DRM pour bloquer les implémentations concurrentes. Bref, conçu pour rester un connecteur de niche, conçu pour ne jamais devenir un standard universel. Donc a fortiori, complètement exclus de toute idée de normalisation. En somme, il n'y a même pas à râler : on va avoir droit à un connecteur universel, et ce ne sera pas Lightning puisque celui-ci a été conçu pour ne pas être universel, fin de l'histoire.

Une friteuse à air, c'est techniquement un petit four à chaleur pulsée, avec un rotor qui permet de brasser en permanence son contenu. Ça permet de cuire des pommes de terre, ou autres, avec un peu de matière grasse, comme on le ferait dans un four normal, en les retournant régulièrement.

Le résultat ressemble un peu à des frites, mais c'est moins gras, encore que ça dépende de la quantité de matière grasse qu'on y a mis, évidemment, et le goût est différent, assez pour se rendre compte qu'il ne s'agit pas de frites normales. C'est assez bruyant, et assez simple à utiliser et à nettoyer.

(Et ça marche sans problème avec de la graisse de canard, c'est important ça.)

Joli. C'est l'équivalent sémantique d'une contrepèterie je dirais :

On ne pourra s'empêcher de voir dans la date un choix hautement significatif - quelle entreprise en effet, mieux qu'Apple, aura œuvré pour l'accessibilité du digital aux femmes

Je n'ai pas la réponse à ta question car elle m'intéresse également, cela me semble être une sorte d'exception à la philosophie Unix "tous est fichier (normal ? )"

Non, tout est dans la parenthèse, que tu as ajoutée de ton propre chef. Tout est fichier, tout court. Tout n'est pas fichier régulier.

Je me demande si ce n'est pas dû au fait que les loopback sont liées au fichiers de type ISO (genre image cd cdrom/dvdrom) et que cela serait lié au format même de l'iso ?

Pas tout à fait. La plupart des systèmes de fichiers sont censés être sur périphérique bloc, c'est le cas d'ISO 9660 et UDF, mais aussi d'Ext4, etc. En revanche, quelques systèmes de fichiers particuliers, comme les systèmes de fichier réseau, ou encore les tmpfs, ne demandent pas un périphérique bloc, mais quelque chose de très différent.

Donc, en un sens, oui, c'est lieu au format ISO 9660 ou UDF, dans le sens où ce sont des systèmes de fichiers ordinaires, dont l'implémentation sous Linux nécessite un périphérique bloc, comme l'immense majorité des systèmes de fichiers.

Petite précision tout de même, si l'appel système mount(2) n'accepte pas les fichiers réguliers, la commande mount(8) les accepte, grâce à l'option -o loop, avec laquelle elle alloue automatiquement un périphérique boucle.

Et par-contre l'appel système mount lui il peut pas travailler sur un fichier ?

Si, mais pas sur un fichier régulier, seulement sur un fichier de type périphérique bloc. Un périphérique bloc est un fichier, d'un type particulier. Outre les fichiers réguliers, il y a plusieurs types de fichiers : répertoires, liens symboliques, tubes nommés, sockets unix, périphériques caractère, périphériques blocs, etc.

La raison pour laquelle mount(2) a besoin d'un périphérique bloc, c'est qu'à mon avis le noyau doit vouloir accéder aux données du système de fichiers directement à des adresses mémoire. Un fichier régulier n'a rien de tel, à moins de le mapper en mémoire, et c'est justement ce que fait un périphérique boucle.

Lorsque tu manipules des périphériques blocs avec des commandes comme cp, cat et compagnie, ces logiciels les utilisent en y faisant des appels systèmes d'ordinaire utilisés pour des fichiers réguliers, mais qui sont aussi implémentés pour les périphériques bloc, qui font en fait « plus » que des fichiers réguliers.

Au fait, c'est le genre de chose à ne faire que si le message n'est pas en échec SPF. Parce qu'un échec SPF, c'est signe d'un expéditeur d'enveloppe falsifié, donc auquel il ne faut surtout pas envoyer de rebond, puisque ce n'est pas lui qui a envoyé le message.

Attention, j'ai bien dit pas en échec SPF, ce qui n'est pas synonyme de succès SPF. Un message peut très bien être en SPF neutre, ce qui prouve simplement que l'administrateur du nom de domaine de l'expéditeur d'enveloppe ne se préoccupe pas du problème de la falsification possible d'adresse électronique.

Ça s'appelle des messages rebond, et c'est une vraie plaie, pour plusieurs raisons, l'une d'entre elles étant que le message rebond suite à un spam dont l'expéditeur d'enveloppe est falsifié arrivera à quelqu'un qui n'a rien à voir avec ce spam. Dans l'idéal, il faudrait refuser les messages qu'on ne peut pas ou ne veut pas accepter.

Ah, ça montre deux choses, ici :

• les chaînes de télé ne peuvent pas attaquer, ou en tout cas pas gagner, contre les fabricants ou vendeurs de systèmes d'enregistrements ;
• pour un fournisseur de service incluant une réception et un enregistrement de chaînes publiques, typiquement un FAI avec service de télévision inclus, la Hadopi considère qu'il est abusif de ne donner aucun accès normal à ces enregistrements.

Le premier point ne me surprend guère, ce serait un précédent tout à fait regrettable, parce qu'il permettrait de s'attaquer à des fournisseurs de n'importe quel objet dès que quelqu'un l'a utilisé pour faire un truc interdit. Un enregistreur, ça permet de faire une copie privée, qui devient publique dès qu'on la diffuse, ce qu'on n'a pas le droit de faire. Mais un couteau, ça permet de cuisiner et de manger, comme de blesser quelqu'un, ce qu'on n'a pas le droit de faire. Ça s'appliquerait à n'importe quoi.

Ce serait sans doute un peu différent si un enregistreur TNT incluait un bouton « partager avec BitTorrent et diffuser le lien magnet sur Facebook ».

Oh, ça doit pouvoir se faire sans problème avec des trucs un peu souples, avec Mutt par exemple, il faudrait :

1. coder un script qui prend un message sur son entrée standard, qui génère un message rebond et l'envoie à l'adresse d'expéditeur d'enveloppe ¹ ;
2. définir une touche de raccourci qui passe le message courant à ce script.

Ça pourrait aussi se faire côté serveur IMAP, avec Dovecot en tout cas, avec une action Sieve déclenchée à l'ajout d'un message dans un dossier dédié à cela. Mais c'est déjà bien plus tordu.

Ah, mais aucune loi ne demande aux fabricants de matériel HDMI d'implémenter ce truc. C'est un concept qui relève des contrats privés, pas de la loi.

La loi réprime le craquage de ce genre de truc, mais n'impose rien du tout en matière de chiffrement.

Mais il n'y a besoin de rien du tout pour donner l'illusion de quoi que ce soit, ce sont des enregistreurs, par nature, ça ne fait que ça, de la copie privée ! C'est l'équivalent moderne de l'enregistrement de la radio sur cassette, ce qui est l'archétype de la copie privée en fait.

Et personne ne demande au fabricant de prouver que ce qu'il vend sert à faire de la copie privée, en plus. Pourquoi feraient-ils du zèle ?

EDIT : Mais de toutes façons il me semble bien que tous les enregistreur TNT chiffrent, et c'est très sûrement une obligation légale.

Ça m'étonnerait, ne serait-ce que parce qu'il existe visiblement plein d'appareils qui justement, ne chiffrent pas. Et plein de logiciels aussi. Je vois mal ce genre de truc figurer dans la loi, surtout s'agissant de flux qui sont par nature, publics, donc dont la diffusion, volontairement ouverte, est impossible à contrôler.

Sans compter qu'un enregistreur TNT, ça peut aussi être n'importe quel décodeur TNT → HDMI couplé à un enregistreur HDMI, encore plus impossible à réguler. Je sais que les députés sont parfois ignares, mais ce serait ridicule, une loi interdisant de vendre des trucs qui enregistrent un flux public sans le chiffrer. Sans compter qu'il faudrait y associer un description de ce qu'on appelle chiffrer, une interdiction de donner accès à une clef pour déchiffrer, etc.

Interdire d'enregistrer tout court, ça pourrait déjà être dans la loi de façon plus cohérente (pas plus défendable, hein), sauf que non, c'est plutôt l'inverse qui y figure en fait.

Ça, c'est comme tous les appareils qui dépendent d'un service externe ou en l'occurrence, d'un format qui n'est pas ouvert. Il faut être conscient, lorsqu'on l'acquiert, qu'il ne s'agit pas vraiment d'un achat mais d'une location à terme inconnu déterminé par le seul fournisseur.

Vous achèteriez un appareil photo qui stocke des photos, mais sans possibilité de les en sortir ? Personnellement, c'est parmi les premiers trucs que j'essaie, et si je ne trouve pas moyen d'extraire les photos, je renvoie illico l'appareil pour me le faire rembourser. Je n'ai pas d'enregistreur TNT, mais si j'en avais un, c'est aussi une des premières choses que j'aurais vérifié.

Bref, là c'est trop tard, mais attention à l'avenir, lorsqu'on achète un appareil, il faut toujours penser à ce que ça donnera dans cinq ans, dans dix ans, s'il ne s'allume plus, si le fournisseur coupe le service, si l'écran ne fonctionne plus, ce genre de truc.

C'est le besoin de type union qui m'a rappelé Caml, en rédigeant ça en Python, en fait.

Ça pourrait être sympa en (O)Caml, aussi.

Et pour les nombres cités :

% ./trouve.py 1 4 5 6
(6 / ((5 / 4) - 1)) = 24

Correction, en utilisant les rationnels du module standard fractions :

#! /usr/bin/python3
import argparse
from fractions import Fraction
add = Fraction.__add__
sub = Fraction.__sub__
mul = Fraction.__mul__
div = Fraction
signes = {add: '+', sub: '-', mul: ×ばつ', div: '/'}
class Operation:
 """An operation between two integers, fractions or operations"""
 def __init__(self, a, b, op):
 """Return an operation representing 'a op b':
 a, b integers, fractions or operations
 op operator"""
 self.a = a
 self.b = b
 self.op = op
 self._result = None
 def result(self):
 """Return the result of the operation, as a fraction"""
 if self._result is None:
 a = value(self.a)
 b = value(self.b)
 self._result = self.op(a, b)
 return self._result
 def __str__(self):
 return '(%s%s%s)' % (self.a, signes[self.op], self.b)
def value(a):
 """Return the value of an integer, a fraction, or the result of an operation"""
 if isinstance(a, Operation):
 return a.result()
 else:
 return a
def operations(a, b):
 """Yields of feasible operations between two integers, fractions or operations"""
 yield Operation(a, b, add)
 yield Operation(a, b, mul)
 yield Operation(a, b, sub)
 if value(b) != 0:
 yield Operation(a, b, div)
def calculs(*termes):
 """Yields all feasible computations with multiple integers or fractions"""
 l = len(termes)
 if l == 1:
 # Un seul terme, rien à faire à part le renvoyer tel quel !
 yield termes[0]
 else:
 # Au moins deux termes: on en prend un...
 for i in range(l):
 a = termes[i]
 # ... puis un autre
 for j in range(l):
 if i == j:
 # Ce sont les mêmes termes, ce n'est pas ce qu'on recherche
 continue
 b = termes[j]
 # On parcours les opérations possibles entre eux
 for ab in operations(a, b):
 # On considère le résultat de cette opération comme un nouveu terme
 # remplaçant les deux choisis.
 yield from calculs(ab, *[termes[k] for k in range(l) if k != i and k != j])
def trouve(nombres, target):
 """Yields all computations of multiple integers or fractions, which result in the given target"""
 for calcul in calculs(*nombres):
 if value(calcul) == target:
 yield calcul
def main(args=None):
 parser = argparse.ArgumentParser(description="Trouve un ou des moyens d'obtenir 24 avec les nombres donnés")
 parser.add_argument("--all", action='store_true', help="affiche tous les calculs donnant ce résultat, plutôt que seulement le premier trouvé")
 parser.add_argument("--target", type=int, default=24, help="cherche un résultat autre que 24")
 parser.add_argument("numbers", nargs='+', type=int, help="nombres à utiliser")
 args = parser.parse_args(args)
 calculs = trouve(args.numbers, args.target)
 for calcul in calculs:
 print('%s = %d' % (calcul, value(calcul)))
 if not args.all:
 break
if __name__ == '__main__':
 main()

Bien vu. Il me faut utiliser des rationnels. Je vais voir ce que je peux faire pour ça.

Pour les fausses informations permettant de justifier des guerres, pas besoin de remonter au Koweït, une bête fiole agitée devant les nations unis suffit pour envahir un pays.

Qu'est-ce que c'est que cette histoire de fiole ?

En Python 3 :

#! /usr/bin/python3
import argparse
add = int.__add__
sub = int.__sub__
mul = int.__mul__
div = lambda a, b: a // b
signes = {add: '+', sub: '-', mul: ×ばつ', div: '/'}
class Operation:
 def __init__(self, a, b, op):
 self.a = a
 self.b = b
 self.op = op
 self._int = None
 def __int__(self):
 if self._int is None:
 self._int = self.op(int(self.a), int(self.b))
 return self._int
 def __str__(self):
 return '(%s%s%s)' % (self.a, signes[self.op], self.b)
# Génère toutes les opérations faisables avec deux entiers ou opérations
def operations(a, b):
 yield Operation(a, b, add)
 yield Operation(a, b, mul)
 yield Operation(a, b, sub)
 if int(b) != 0 and int(a) % int(b) == 0:
 yield Operation(a, b, div)
# Génère tous les calculs faisables avec des entiers ou opérations
def calculs(*termes):
 l = len(termes)
 if l == 1:
 # Un seul terme, rien à faire à part le renvoyer tel quel !
 yield termes[0]
 else:
 # Au moins deux termes: on en prend un...
 for i in range(l):
 a = termes[i]
 # ... puis un autre
 for j in range(l):
 if i == j:
 # Pas le même !
 continue
 b = termes[j]
 # On parcours les opérations possibles entre eux
 for ab in operations(a, b):
 # On considère le résultat de cette opération comme un nouveu terme
 # remplaçant les deux choisis.
 yield from calculs(ab, *[termes[k] for k in range(l) if k != i and k != j])
def trouve(nombres, target):
 for calcul in calculs(*nombres):
 if int(calcul) == target:
 yield calcul
def main(args=None):
 parser = argparse.ArgumentParser(description="Trouve un ou des moyens d'obtenir 24 avec les nombres donnés")
 parser.add_argument("--all", action='store_true', help="affiche tous les calculs donnant ce résultat, plutôt que seulement le premier trouvé")
 parser.add_argument("--target", type=int, default=24, help="cherche un résultat autre que 24")
 parser.add_argument("numbers", nargs='+', help="nombres à utiliser")
 args = parser.parse_args(args)
 calculs = trouve(args.numbers, args.target)
 for calcul in calculs:
 print('%s = %d' % (calcul, int(calcul)))
 if not args.all:
 break
if __name__ == '__main__':
 main()

Le site du jeu m'a proposé les nombres suivants : 1 4 5 6, ce qui m'amène à douter un peu de la garantie que « 100 % des parties ont une ou plusieurs solutions ».

Quoi que, connaissant d'avance la forme des arbres, on peut procéder à l'inverse, du bas vers le haut, et calculer toutes les possibilités de couples, puis les assembler.

Si je ne m'abuse, les résultats intermédiaires se ramènent à une utilisation de parenthèses, et en somme, une solution possible a forcément la forme d'un arbre binaire, les opérations utilisées ayant à chaque fois deux termes. Même si plusieurs arbres peuvent être équivalent à cause de la commutativité de l'addition et de la multiplication.

Bref, des arbres binaires avec quatre feuilles, il n'y en a pas trente-six, en fait il n'y en a que deux si je ne m'abuse, les autres formes possibles étant équivalentes à celles-ci en échangeant des nombres :

 /\ /\
a /\ / \
 b /\ / \
 c d /\ /\
 a b c d

Donc, deux formes d'arbres, 4! répartitions des quatre nombres, et, les arbres ayant 3 nœuds sur lesquels il faut choisir à chaque fois une opération parmi les quatre opérations de base, 43 choix d'opérations. Soit un total de 3072 possibilités. Je me trompe ?

On pourrait envisager d'optimiser le calcul en réutilisant des résultats de sous-arbres. Cela implique d'utiliser une forme de cache, et je ne suis en fait pas certain que ce soit vraiment plus efficace que de calculer sans cache. Un avis ?

Peu de chance, je pense, en tout cas ce n'est vraiment pas mon cas. Ça me cassait les pieds de devoir recevoir deux doses la première fois, alors qu'une aurait suffi compte tenu de mon infection passée, mais je les ai fait sans trop rechigner.

Ça me cassait les pieds de faire une troisième dose alors que j'étais censé être déjà assez blindé avec une infection et deux doses, mais je l'ai fait en rechignant encore moins, puisque je connaissais déjà les effets de la vaccination : mal à l'épaule pendant deux jours et rien de plus. Je m'en serais bien passé vu que je suis censé ne pas avoir besoin d'autant de doses, mais bon, mon cas n'est dans aucune case prévue, donc tant pis.

Ça doit être assez faisable tout de même, parce que lors de la première vague de vaccination, l'été dernier, à un moment, on s'était mis à tester les anticorps des gens qui disaient avoir eu la Covid mais n'avaient pas de preuves l'attestant. Mon cas, quoi. Sauf que j'ai été vacciné juste avant que ces tests ne soient mis en place, et que malgré mon infection passée, j'ai donc eu droit à deux doses. Avec la troisième que j'ai reçue il y a peu, ça devrait me faire une immunité en béton armé, au moins.