flan a écrit 1848 commentaires

À nouveau, Apple est vraiment un cas à part vu qu’ils ne vivent pas de ça. Ce qui ne veut pas dire qu’ils ne le feront jamais, bien sûr, mais a priori ils ont l’air de faire de cette particularité un argument de vente.

Si Google comme Facebook vivent de données personnelles, ce n’est pas le cas d'Apple qui vit du matériel vendu (un bras) et des services (qui n’ont pas d’intérêt sans le matériel).

Le keylogger est pour la récupération du n° de carte de crédit.

Même pour ça : je ne suis pas du domaine (mais alors pas du tout), donc je n'ai aucun moyen de savoir si faire des relevés est à la portée de tout le monde (il y a plein de domaines où faire des mesures est compliqué), ni s'ils sont capables de le faire.

Il ne dit pas que ça ne coûte presque rien, il dit que ça coûte moins cher pour un résultat plus fiable.

Mais que vaut la CRIIRAD ?

Sauf que les nouvelles générations de réacteurs permettent de diviser la consommation par 10 environ (la 4ème génération doit permettre de diviser par 50 à 100 mais on va rester pessimiste).

Ça change tout : ça donne entre 300 et 500 ans devant nous.

L'absence de pilotage des ressources renouvelables joue beaucoup, c'est pour ça que même si les Allemands ont augmenté la part moyenne de renouvelable dans leur énergie, ils n'ont pas diminué le nombre de centrales classiques.
Si on augmente la part de renouvelable dans notre énergie, on aura toujours besoin d'autant de centrales qu'avant, sauf qu'elles seront moins utilisées en moyenne.
Or le risque et le prix d'une centrale est quasi-indépendant de son utilisation (en gros, c'est du tout ou rien). Donc on paierait toujours autant pour du nucléaire qu'on utiliserait moins, mais en plus on paierait pour du renouvelable inutile (sans compter tous les problèmes liés).

Concernant le dernier point, il parle probablement du nombre de morts de l'Axe et non alliés pour mesurer la contribution sur chaque front. Sinon, en effet, le front de l'Ouest a été plus efficace.

OpenPyxl est pas mal également pour manipuler des feuilles Excel

https://openpyxl.readthedocs.io/en/stable/

Je pensais plus au premier cas, en effet (machine solo), mais même dans le second, il y a potentiellement un peu de travail à faire sur la machine cible (configuration réseau si elle est un peu complexe, injection des clefs publiques si absence de mot de passe, etc.). Mais bon, dans tous les cas c'est un travail à faire :)

Par expérience :
- le méta-paquet est une mauvaise idée (cycle de vie du paquet à gérer, ainsi que les miroirs APT, les clefs GPG, …) dans tous les cas,
- si on utilise un preseed (installation de l'OS automatisée), sa phase de post-install doit être minimale (en gros permettre la configuration par ansible, puppet ou tout autre équivalent) et ne surtout pas faire autre chose,
- le bash est une mauvaise idée car trop dur à maintenir quand il est complexe.

Mais bon, c'est assez rassurant qu'Ansible, pensé pour configurer des machines soit meilleur dans ce domaine qu'un Bash qui est très généraliste.

En résumant : tout fonctionne (d'autres logiciels avec le même protocole HTTP/HTTPS ou d'autres protocoles) sauf deux logiciels bien précis. Ça élimine directement un problème réseau.

À partir de là, je ne vois pas trop comment mettre ça sur le dos d'Orange.

J'aurais tendance à dire que Chrome et Firefox reprennent tous les deux les réglages du système et wget les ignore.

Mon point de vue sur la question :
- ansible réclame une passe après installation (donc installer Ansible) et il faut pouvoir récupérer facilement le script (pas forcément compliqué, cela dit),
- le preseed est un peu complexe à faire évoluer (faut refaire une image et c'est pénible), c'est pénible à débugguer et on ne peut pas le reclaquer facilement,
- le metapaquet est un peu complexe à régénérer, potentiellement ça implique d'avoir un miroir Debian (avec la gestion de clefs que ça implique), c'est pénible à débugguer et il faut en plus s'occuper de la montée de version
- le script bash va demander de réinventer pas mal de choses par rapport à Ansible (pour le structurer, pour assurer l'idempotence, …) et sera plus compliqué à prendre en main par quelqu'un d'autre.

(Plus exactement, commitstrip n'est pas traduit en français, il est d'abord en français puis traduit en anglais)

La 5G est censée venir avec de la QoS implantée très profondément pour permettre de garantir des applications à très faible latence comme les voitures autonomes (en réservant par exemple des bandes de fréquence et en rapprochant des fonctions critiques des utilisateurs).

Enfin, c'est en tout cas le discours qui est vendu.

Pour le nombre d'accidents, il suffit de comparer le nombre d'accidents par kilomètre avec une voiture moderne (les Tesla) dans des conditions idéales (autoroute, essentiellement) avec la même valeur, mais avec des voitures quelconques (sans freinage d'urgence automatique, par exemple) dans des conditions quelconques (en ville, notamment, là où la voiture autonome est actuellement la moins douée).

Dans macOS, il n'y a pas tant de BSD que ça : le micro-noyau Mach lui-même vient de NeXTSTEP, la couche graphique vient d'Apple et de NeXTSTEP. La partie venant de BSD correspond aux outils autour du micro-noyau (comme c'est à la base un micro-noyau, ce n'est pas le même découpage que Linux, mais en très gros, XNU qui est Mach + les outils BSD correspond au noyau Linux).
Mais bon, ce n'est pas tellement ça qui fait l'intérêt de macOS (ils pourraient passer à Linux ou NT que ça ne changerait rien pour 99% des utilisateurs).

De ce que j'ai compris sur D-Wave, ce sont à la base des acheteurs de brevets compulsifs qui ont pensé faire une bonne affaire en ciblant les brevets sur les ordinateurs quantiques dans le but de faire payer les premiers constructeurs.
Manque de pot, comme ça mettait un peu de temps à se concrétiser, ils ont dû trouver quelque chose à vendre.

Merci pour le lien !

Ou alors, les développeurs de macOS préfèrent zsh (qui est fourni de base depuis fort longtemps) ; est-on sûr qu'il s'agisse d'un problème de licence ?

un peu comme webkit, cups, llvm, … ?

Dans le code principal.
Avec un ORM, on aura donc une équivalence classe <=> table SQL, et instance <=> ligne de la table.

>>> class A:
>>>   owner_type_id = CharField("module.class") # ou tout autre identifiant de classe ORM
>>>   owner_id = IntegerField() #  clef primaire de l'objet en question
>>>   
>>>   def owner(self):
>>>     return self.owner_type_id.get_by_id(self.owner_id) 


>>> owner_1 = B()  # instance quelconque de l'ORM

>>> instance = A(owner_type_id=owner_1.__class__, owner_id=owner_1.id)

>>> instance.owner == owner_1
True

La classe B (ou C, D, …) n'a à aucun moment besoin d'être connu du code de A, ce qui est bien pratique s'ils sont dans des plugins codés par d'autres entités.

Mais en pratique, c'est rare (ou plutôt rarissime) d'avoir des spécifications formalisées au point de pouvoir prouver quoique ce soit (déjà qu'avoir des spécs n'est pas donné à tout le monde)…

Mais comment fais-tu ton type somme si tu ne sais pas quels sont les sous-types de ce type somme ?
Potentiellement, le code des classes D, E, F… sont créées de façon indépendante, sans que le code principal contenant A et B ne soit modifié (mettons que F est fournie par un plugin tierce-partie, qui ne peut pas modifier A).

Cas très classique avec Django : tu as trois classes qui sont des Model de l'ORM (une classe correspondant à une table SQL avec un attribut pour chaque colonne, une instance correspond à une ligne), qu'on va appeler A, B, C.

A doit être lié soit à une instance de B, soit à une instance de C (sachant qu'en vrai, ça peut être soit à, B, C, E, F, …).
En pratique, on a donc deux attributs, un qui indique quelle classe (B ou C) et le second indique la clef primaire au sein de la classe en question.
Enfin, un a un troisième attribue qui a donc un type dynamique (variable en fonction de l'instance de A) qui sera une instance de B ou C.