🚲 Tanguy Ortolo a écrit 12197 commentaires

Il faut regarder l'écosystème qui est énorme, ça ne concerne pas que la recharge, ça concerne l'audio, la vidéo (dans une moindre mesure), les docks, les enceintes… Les usagés qui ont investi dans cet écosystème pour le long terme, Apple c'est aussi un peut de stabilité, se retrouvent bien niqués.

Ce n'est pas un problème, pour plusieurs raisons :

1. Apple ont déjà, dans le passé, changé de connectique. Le fait que ça arrive à nouveau ne surprendra aucun utilisateur, ou alors seulement ceux qui ont la mémoire très courte.
2. Un usager qui se soucie vraiment de la pérennité de la connectique n'achète pas Apple, ou alors ce n'est pas vraiment son souci principal. Parce que justement, Apple sont connus pour avoir changé de connectique dans le passé, tandis que l'intégralité des autres fabricants n'ont changé que pour passer à une connectique unique, la même pour tous, l'USB-C. Choisir Apple, ce n'est pas un choix de pérennité de la connectique, c'est un choix motivé par ce qu'on veut, mais pas par ça.
3. Racheter du matériel, ce n'est à l'évidence pas un problème pour les gens qui compte mettre un bras dans un téléphone Apple. Pour faire ça, il faut être soit riche, soit pas riche mais très con, donc ce genre de problème peut être ignoré.

Rappelons que le cas que tu évoques, c'est quand même celui de quelqu'un qui a un téléphone Apple avec connecteur Lightning, un dock assorti, et qui envisage d'acheter un nouveau téléphone Apple avec connecteur USB-C. Son dock ne fonctionnera pas avec le nouveau téléphone, mais depuis quand est-ce un problème puisqu'il sortira de toute façon des centaines d'euros pour acheter son nouveau téléphone ? Il pourra bien rallonger un peu pour acheter un nouveau dock. Ou alors, passer à autre chose qu'Apple, si l'argent est un problème.

Le gros point pour le lightning c'est que par design, c'est vachement plus robuste que de l'usb c. coté connecteur, c'est juste un trou. Cote cable, c'est juste un bout de metal. Pas de zigwigwi qui dépasse dans le connecteur, pas de prise "creuse" cote cable.

Sans doute, mais ce point ne pèse pas lourd face à l'inconvénient majeur de Lightning, qui est par conception, volontairement, un connecteur de niche qui n'a aucune vocation et aucune chance de devenir un standard.

Pour dire les choses autrement : concevoir un connecteur génial, c'est super, le concevoir en faisant en sorte qu'il ne s'impose jamais, c'est débile, et c'est exactement ce qu'ont fait Apple.

Ç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, 4³ 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 ?