Renault a écrit 7453 commentaires

Je ne pense pas que mon commentaire soit radicalement différent selon la définition adoptée.

Disons que par exemple quelqu'un qui qualifie les IA actuelles comme intelligentes devraient être capables d'expliciter si :

• L'IA est consciente d'elle même ;
• L'IA ressent des sentiments d'une façon ou d'une autre ;
• En conséquence, est-ce que l'IA doit avoir un cadre juridique propre similaire à celui des animaux ou des humains avec tout ce que cela implique ?

Ce sont des notions connexes, c'est à mon sens bizarre de les considérer intelligentes et de ne pas réfléchir sur ces points. Et si on répond positivement aux deux premiers points, c'est assez intenable de ne pas le faire sur le 3e.

Et si on se base sur une approche comportementale pour définir l'intelligence, on devrait faire de même pour ces points là, donc en théorie arnaudus devrait par exemple admettre ces trois points. Ou alors trouver une bonne raison pour accorder l'intelligence mais ne pas le faire pour ces éléments là mais ça me semble compliqué si on utilise les mêmes méthodes à mon sens.

En tout cas, bref, j'ai de plus en plus de mal à supporter l'argument de la cible mouvante pour l'IA. Depuis des siècles, on redéfinit l'intelligence dès qu'on crée une machine capable de faire une tâche qu'on pensait définir l'intelligence (calculatrice, ordinateur qui joue aux échecs, traduction, test de Turing, etc).

Ou alors c'est juste que les jalons posés avant n'ont aucun sens et que de "reculer" a de fait du sens car on doit préciser ce qu'on attend de cette notion ? Il faut dire que jusqu'à très récemment c'était assez facile de ne pas se poser la question.

Le sujet est difficile et personnellement je suis peu convaincu par l'approche purement comportementale car il y a de nombreuses limites mais c'est malheureusement le mieux que ce qu'on a aujourd'hui. Même si je ne crois pas non plus que la simple propriété "organique" soit nécessaire pour atteindre ce stade.

Je ne vois pas en quoi se barricader dans le déni va servir à quoi que ce soit.

Je pense qu'il faut faire attention avant de proclamer trop vite que "l'IA" est intelligente car si on pousse le raisonnement on devrait rapidement conclure des choses qui ont des implications profondes. Bien définir me semble donc indispensable. Et donc il faut être prudent.

Admettons que l'IA est intelligente, quoique cela veut dire, alors la question suivante est de savoir ce qu'on fait de cette notion et de se poser des questions connexes.

L'IA a t elle conscience d'elle même ? Ressent-elle des choses ? A-t-elle des sentiments ?

Si elle est intelligente, elle devrait rapidement avoir une personnalité juridique à définir. Car cela signifie qu'elle peut faire des actions qui ont des conséquences et qu'elle en a à priori conscience car l'entité est intelligente. Elle devrait donc être responsable notamment devant la loi.

Mais cela est vrai dans l'autre sens. Est-ce que éteindre le conteneur qui exécute le code de l'IA cela revient à la tuer ou à l'endormir ? Serait-ce donc criminel d'interagir avec elle de certaines façons ? Ou de frapper un robot qu'on a acheté dotée d'une telle IA ? Est-ce que manipuler l'IA en code, en entrainement ou interagir avec de certaines façons ne violeraient pas de nombreuses lois qu'on applique aujourd'hui aux humains et que par conséquent on devrait éteindre cela à ces sujets ? Pourquoi on ferait la différence entre humains et IA dans le fond ?

Alors bien sûr on n'est pas obligé de conclure tout cela et de dire "c'est intelligent" et on ne se pose pas plus de questions. Mais cela me paraît naïf et assez peu éthique car on essaye pas de prendre la mesure de ce que cela implique alors qu'on a "potentiellement" devant nous des entités intelligentes qui pourraient être dotées d'une conscience de manière émergente.

Actuellement mon temps est trop précieux pour passer 15 / 20 minutes (?) (en réalité c'est BEAUCOUP plus car un simple arrêt en station juste pour faire un pipi ultra rapide casse énormément votre moyenne et retarde déjà énormément l'heure d'arrivée, donc ces fameux "20 minutes" de recharges me laisse dubitatif), en conséquence m'arrêter pour recharger à chaque fois et perdre 30 minutes ~ sur le trajet m'irriterait fortement.

Si la charge dure 20 minutes, elle dure 20 minutes. Tu peux arrondir max à 25 minutes le temps de sortir, prendre le câble, brancher / payer, mais c'est tout. Cela ne change pas l'ordre de grandeur tout ça.

Bon après c'est amusant de considérer que 30 minutes de perte de temps sur un trajet de 3-4h ça vaut le coût de détériorer encore plus la planète, le confort avant tout manifestement.

"Oui mais tu peux demander à te charger chez la personne chez qui tu vas" (lol?). Je trouve que cela tout à fait impoli : l'électricité coûte cher, les factures que l'on reçoit me font déjà tourner de l'oeil actuellement.
Si quelqu'un venait (même de mes proches) me demandait ça avec sa voiture électrique en venant chez moi je le présente mon IBAN.

À titre perso, dans ce cas je payerais volontiers la personne chez qui je me recharge, surtout si c'est régulier. Ou à l'inverse si j'avais régulièrement de la visite avec des gens qui se chargeraient chez moi, je demanderais une petite participation que ce soit en argent ou autrement. Cela ne me choquerait pas.

Je trouverais ça encore plus malpoli que l'hôte refuse un tel arrangement et dise "recharge toi dans la rue" où c'est plus cher et prend du temps.

Oui bien sûr, d'autant qu'on peut aussi miser sur le fait que la centrale à charbon est mieux entretenue et optimisée qu'une voiture lambda.

Mais l'objet c'est surtout de montrer que le gain est d'autant plus énorme qu'on ne se repose pas sur les énergies fossiles pour produire l'électricité.

Pour qui ? Dire que les stores sont des bonnes choses (surtout étant donné ceux que je cite)… J'aurais jamais cru lire ça sur linuxfr.

Car tu mélanges tout. Le problème n'est pas l'existence des stores, c'est la possibilité d'avoir des alternatives.
C'est très bien qu'un OS ait un store, c'est gênant si tu n'as pas le droit d'installer quelque chose d'en dehors d'un store unique.

Sinon le fait qu'une distro ait des dépôts devrait te faire bondir car c'est finalement la même chose.

Avec Flatpak et l'OS atomique tu peux installer des logiciels de différentes sources, Flatpak supporte des dépôts, tu peux créer le tien si tu veux par exemple. Donc je ne vois pas le problème.

La sécurité, bien souvent, c'est pas un problème technique mais un problème humain. Prétendre résoudre un problème humain avec une solution technique, c'est ne pas avoir compris le problème.

C'est un problème humain et technique. La technique reste important dans ce contexte et tu ne peux l'enlever.
Sinon j'imagine que tu es superutilisateur en permanence, que tu envoies tes mots de passe en clair partout où tu te connectes, etc. ?

Et oui il y a des conceptions logicielles plus sécurisées que d'autres, parfois au détriment d'autre chose, c'est une affaire de compromis évidemment.

Sauf que toutes ces solutions, y compris celles proposées dans ce journal se heurtent à l'humain qui, quand une application va lui demander des droits pour pouvoir fonctionner, va sans doute appuyer sur oui sans bien comprendre les implications. Aucune solution technique ne peut résoudre ce problème. Pas plus les anciennes que les nouvelles.

Ce n'est pas la solution miracle, mais ça évite des problèmes tout de même. Et ceux qui ont conscience de ces enjeux c'est un complément appréciable. Je suis bien content que par défaut une application ne puisse pas à priori prendre une photo de la webcam ou des captures d'écran sans que je n'y autorise par exemple dans mon dos. Cela nécessite une architecture particulière pour que cela soit possible.

De toute façon la sécurité n'est pas le seul enjeu ici, c'est un élément parmi d'autres.

En fait, je ne vois pas bien les avantages de ce système. Il n'apporte pas grand chose de plus par rapport à l'existant.

Pourtant, dans les commentaires on a plusieurs fois expliqué ces avantages, que cela ne t'intéresse pas ou te paraissent secondaire c'est ton droit, cela ne veut pas dire que ton point de vue est universel.

Et en revanche, je vois bien les inconvénients, dont certains me paraissent assez contradictoires avec les buts premiers des logiciels libres en général.

Ce genre de propos n'a vraiment aucun sens.

Un logiciel libre ne signifie pas que par défaut le logiciel doit laisser l'utilisateur faire n'importe quoi n'importe comment. C'est juste que si l'utilisateur n'est pas content, il peut modifier (lui même ou via un tiers) le code pour s'adapter à son besoin. Les considérations de configuration et de souplesse à l'usage n'a rien à voir avec le caractère libre ou pas du logiciel. Tu peux avoir du libre très peu flexible et du proprio qui l'est énormément. Ce n'est pas l'enjeu ici.

D'ailleurs, tu le dis toi même, Linux fournit déjà beaucoup de restrictions pour des raisons de sécurité. Linux n'est donc pas libre ? On devrait bypasser la MMU pour être libre de notre machine car jardiner en mémoire c'est une liberté fondamentale ? Pourquoi le système tel qu'il est aujourd'hui malgré ses restrictions c'est "logiciel libre compatible" mais les mêmes logiciels organisés un peu autrement ne le seraient pas ? Tu définis comment la limite de l'acceptable ?

Ici tout le système est libre, tout autant qu'une distro classique en fait, donc ça n'a rien de contradictoire. On peut même ajouter que pour de nombreux utilisateurs, être capables d'installer un logiciel facilement sans dépendre de sa distro c'est une liberté plus importante que d'avoir par exemple un système de fichiers du système en lecture / écriture en permanence.

C'est peut être plus intéressant aussi d'avoir la possibilité de dire à l'application de chat de sa boîte de ne pouvoir accéder qu'à certains dossiers liés au travail plutôt qu'à tout le répertoire utilisateur.

Comme si c'était une nouveauté… On peut déjà le faire aujourd'hui ça. Ça donne vraiment l'impression qu'on réinvente la roue carrée.

Ah bon, tu fais ça comment qui fonctionne sur toutes les distros ? Et qui fourni un bac à sable avec la possibilité de restreindre les permissions au cas par cas selon les besoins et envies ?

Oui c'est faisable, mais en terme d'expérience utilisateur c'est vraiment compliqué à mettre en place proprement et encore plus de le faire de manière générique.

Mouais, on connaît ce discours hein…

Tu as des éléments de penser que toutes les distributions deviendront atomiques ?
Soyons sérieux, même dans les promoteurs de la techno je ne connais personne qui pense que cela remplacera les distros actuelles entièrement.

Pour que cela remplace l'ancienne manière de faire, ça veut dire que les avantages ont tellement surpassé les inconvénients qu'il n'y a plus assez de mainteneurs pour faire comme avant. On n'y est pas à ce jour et on est loin d'un consensus que cela sera vrai un jour.

Je doute que cela arrive un jour car les avantages et inconvénients de chaque modèle sont impossibles à converger. Donc selon les cas d'usage, une approche sera meilleure que l'autre.

Et quant à dire que c'est ça qui va assurer la popularité de Linux (hors embarqué) pour le grand public

Cela est pourtant utile pour le grand public qui a en fait un bénéfice plus important de cette conception que le lecteur moyen de linuxfr.org. Est-ce suffisant ? Certainement pas, et personne ne pense que c'est la solution magique, mais pourquoi ne pas essayer ?

En fait c'est amusant, on parle de liberté, de pouvoir changer le code pour adapter à ses besoins et tout mais il y a un conservatisme énorme sur ce genre de sujets. Si des développeurs veulent faire un Linux atomique pour les avantages qu'ils peuvent procurer, pourquoi on devrait les en empêcher ou critiquer la démarche ? D'autant qu'il y a de bons arguments pour un tel modèle (mais aussi de vrais arguments contre, évidemment).

Qu'ils essayent, qu'ils expérimentent et on verra si la sauce prend ou pas.

C'est une question de rendement. Un moteur électrique a peu de pertes (moins de 10%) contre 65-70% de pertes pour un moteur thermique.

On ne le réalise pas mais un réservoir de 50L d'essence c'est en énergie équivalent à une batterie de 484 kWh.
Une voiture électrique consomme entre 10 et 25 kWh / 100 km. Une voiture thermique avec une consommation de 5,5 L d'essence (ce qui est assez courant) c'est l'équivalent à 53 kWh / 100 km.

On ne réalise pas en fait qu'une voiture thermique consomme énormément d'énergie et que la majorité de celle-ci est gâchée : la chaleur produite chauffe l'air et c'est tout. Une faible partie sert à avancer. La voiture électrique a un très bon rendement.

Bon c'est sûr que si l'électricité vient exclusivement de centrales à charbon, cette efficience n'apporte pas grand chose car la perte sera au niveau des centrales électriques. Cependant et notamment en Europe, il y a assez de renouvelable / nucléaire pour que ça ne soit pas un problème et que le gain réel soit énorme.

On est quelques uns à être dubitatif sur le sujet parce que les exemples cités donnent plutôt l'impression d'enfermer l'utilisateur plutôt que de le libérer. Mais c'est pour son bien, paraît-il ! C'est la logique d'Android, c'est la logique de MS et de bien d'autres : limiter ce que peut faire l'utilisateur pour des raisons de «sécurité», et in fine le faire passer par des stores officiels.

Et c'est dans la pratique une bonne chose.

Ton système Linux "libre" ne te permet pas de faire tout et n'importe quoi non plus pour des raisons de sécurité. Tu as des utilisateurs avec des droits différents par exemple et par défaut tu n'es pas superutilisateur. Est-ce mal ? Non bien au contraire.

La sécurité c'est un sujet compliqué, les logiciels sont compliqués, il y a des failles, des bogues ou des logiciels malveillants dans la nature. Je suis plutôt content qu'on réfléchisse à la question des impacts si quelque chose tourne mal. Firefox a une faille, je suis content qu'il ne puisse pas forcément lire tous les fichiers du système dont des données persos par défaut. Et si pour un besoin X ou Y je veux faire ça, je peux le lui autoriser à la volée via un portail ou de manière permanente avec un gestionnaire de permissions.

Je ne vois pas où l'utilisateur a moins de liberté, mais au moins par défaut le comportement est plus sain et plus conforme aux besoins des utilisateurs qui ne s'y connaissent pas techniquement. Car leur demander de sécuriser correctement leur système par défaut, bon courage hein.

Mais grande nouvelle, on peut avoir le même effet avec la liberté en plus, ça s'appelle une distribution Linux, ça existe depuis des lustres. Bref, je ne vois pas l'intérêt du truc non plus.

Ah c'est sûr quand on balaye d'un revers de la main les avantages de ce système et qu'on minimise les problèmes de l'approche traditionnelle, il n'y a pas un grand intérêt effectivement.

En fait, on voit bien la contradiction interne du truc : au départ, on crée snap/flatpak/wtf parce que «ouais mais je pouvais pas installer la dernière version de ce logiciel précis parce que ma distrib était pas à jour donc c'est trop bien snap/flatpak/wtf», et puis ça se transforme en «ok, on ne va plus installer que comme ça», et à la fin, «ha merde, on ne peut plus installer tout un tas d'autres trucs qu'on pouvait installer avant». Donc, retour case départ, mais au passage on a perdu en liberté pour l'utilisateur.

Flatpak et Snap ne sont pas depuis le début juste des paquets universels comme AppImage (ce qui rend d'ailleurs la comparaison frontale entre les deux un peu ridicule car les champs d'action sont différents depuis le départ).

L'approche de la sécurité avec la notion de bac à sable et gestion plus fine des permissions sont là aussi depuis le début en tête et c'est une avancée importante. Le fait de pouvoir installer facilement des logiciels sans droits administrateurs (et donc avec un impact réduit sur le système en cas de défaillance aussi) est également un bénéfice qui a de nombreux cas d'usage.

De toute façon la distro traditionnelle ne disparaîtra pas, et si elle disparaîtra c'est que personne n'a voulu le maintenir en vie pour d'autres raisons. Je pense qu'il y aura une cohabitation des deux approches à long terme selon les besoins. L'atomique ne t'intéresse pas ? Personne ne te force à t'en servir, et personne ne forcera une distro à ne pas fonctionner comme avant. Le code de tout ceci est libre et le restera. L'utilisateur n'a rien à perdre, tout à gagner à avoir le choix justement.

Et c'est bien qu'il y ait des gens qui expérimentent des choses et tentent de proposer des idées nouvelles qui conviendront à certaines personnes même si pas à tous. Il y a des besoins à répondre et les distros traditionnelles ne peuvent pas y répondre en gardant la même approche car il y a forcément des compromis à faire et tu ne peux pas gagner sur tous les tableaux à la fois.

Les seules pannes que j'ai eu viennent du matériel, en général le disque dur.

Comme on te l'a déjà fait remarqué, et moi même par ailleurs, tant mieux que tu n'as jamais eu de soucis mais ce n'est pas le cas de tout le monde.

Pour distribuer un logiciel hors distrib, la méthode KISS est de faire une appimage ou un exécutable avec tout lié en statique.

Pourtant des AppImage qui ne fonctionnent pas car une dépendance de base du système n'est pas compatible ça arrive, ça m'est arrivée, je crois même te l'avoir montré il y a quelques années quand tu faisais la promo de la techno en commentaire.

Le AppImage KISS et parfait distribuable sur tous les systèmes Linux est un leurre. L'approche de Snap ou de Flatpak qui ont des abstractions pour supprimer ces limitations sont la seule possibilité.

Mais le reste, que ce soit la libgtk3 ou le compositeur utilisé par ton gestionnaire de bureau, ça n'a rien de si particulier qui en ferait un truc à considérer comme faisant partie du « système ». Ou alors, je demande à voir quel serait le critère, pour que ça ne dérive pas selon la sensibilité du lecteur.

Le critère dans la plupart des projet atomique c'est que le système qui fonctionne en atomique est le minimum pour démarrer le système et qui soit fonctionnel pour l'utilisateur.

Mais bien sûr ça dépend des usages.

Pour un usage bureautique c'est afficher un bureau où tu peux télécharger / mettre à jour / supprimer des applications. C'est logique en même temps, si un utilisateur novice n'a pas accès à son environnement graphique il ne pourra rien faire, le système est non fonctionnel et il faut revenir à l'état précédent. Si GNOME Shell ne démarre pas car le lien mesa-GTK3 est cassé avec le pilote graphique Intel, le système n'est pas fonctionnel.

Pour un usage serveur ou conteneur, c'est le système minimal qui initialise le matériel et logiciel qui permet de démarrer l'application (ou les applications) souhaitées. Donc là pas besoin d'interface graphique dans la base du système. Le système de base sera plus léger.

En fait tu te concentres sur le critère technique alors qu'ici on se base sur "l'expérience". La notion de système dépend de l'usage que sera fait de l'ordinateur. Pour un serveur inclure GNOME Shell dans la notion de système n'a pas un grand intérêt, pour un utilisateur bureautique ça l'est. Il est donc normal qu'il y a de 'larbitraire car l'objectif est justement de s'adapter à des cas d'usages différents.

Et d'ailleurs, suffit de regarder les autres systèmes. Oui tu parles de Linux+systemd+libc = système sous Linux. Mais sous Windows, le système c'est un tout. C'est le noyau de Windows, son environnement graphique, quelques applications de base, etc. Pareil pour macOS, pour Android, iOS, etc. Et pour beaucoup d'utilisateurs je pense que le curseur de systèmes / application sera différent du tien. En fait tout est arbitraire, la question est de savoir ce qu'on veut faire fonctionnement parlant.

Se concentrer sur l'espace noyau + quelques outils autour c'est trop restrictif, tu ne fais rien avec ça.

mais pour ouvrir un truc avec Firefox il faut que je pense à le copier ou à le lier dans le répertoire « Téléchargements » parce qu'il n'a accès qu'à ça.

Ou alors tu configures les permissions du bac à sable ?

Avec l'application Flatseal par exemple tu peux prendre n'importe quelle application Flatpak et augmenter ou réduire les droits. Tu veux donner accès à tout le système de fichiers de la machine à Firefox ? Tu le peux. Uniquement le répertoire utilisateur ? Tu le peux aussi.

Et c'est justement un gros point fort. Tu utilises une application car tu en as besoin mais tu n'en as pas une confiance absolue (genre logiciel proprio pour le boulot), hop dans le bac à sable avec les paramètres que tu veux.
Ou à l'inverse, Firefox est libre mais c'est gros, ça a des bogues, des failles de sécurité, tu peux réduire au maximum les accès en fonction des besoins pour limiter les dégâts.

Et c'est très bien, c'est un atout réel.

J'ai quand même l'impression que dans ce fil tu n'as pas beaucoup expérimenté et que tu émets des critiques qui n'ont pas lieu d'être. Sans dire que c'est parfait, c'est bien plus puissant et fonctionnel que tu ne le penses.

De même pour Linux, il existe des tas de solutions pour changer le kernel en live sans redémarrer (typiquement ce qui est fait dans les serveurs cloud, les machines virtuelles ne sont pas interrompues lorsque le porteur redémarre son noyau). Il faut pour cela que les drivers soient capables de correctement sauvegarder leur état et/ou faire un reset propre. C'est exactement la même problématique pour la veille prolongée (hibernation), le noyau sauvegarde ses états sur disque et les recharge en redémarrant. Si tu supprimes la phase "boot" au passage (qui n'a rien à faire lors d'une mise à jour), tu as une mise à jour transparente pour l'utilisateur (au pire, un freeze de quelques secondes pour la récréation des zones mémoires).

Alors le live patching du noyau ça fonctionne mais pas pour tous les correctifs non plus et c'est loin d'être trivial à exploiter.

C'est vraiment conçu comme un moyen de corriger pour de grosses failles ou gros problèmes immédiatement avant de procéder à un redémarrage plus tard à un moment plus opportun comme le weekend ou la nuit par exemple.

De toute façon il faut redémarrer aussi pour la mise à jour de certains composants type systemd ou libc de temps à autres.

La course à l'uptime n'est clairement pas une bonne stratégie de sécurité de nos jours.

Ça ne prouve rien, j'ai pu avoir de la chance, mais est-ce que la différence des formats de paquets et des outils RPM / dpkg peut expliquer ça ?

Non, car ça m'est aussi arrivé d'avoir le soucis avec RPM et relancer la procédure a fonctionné.
Que tu utilises RPM ou DPKG cela ne change rien car mettre à jour un système c'est une opération +/- longue et que si ça s'interrompt au milieu tu n'as aucune garantie que ça fonctionnera bien après.

La seule solution pour n'avoir aucun problème c'est d'avoir la possibilité de faire une mise à jour de manière atomique d'une façon ou d'une autre : si ça fonctionne, tu utilises le système à jour, si ça n'est pas allé au bout, tu gardes le système tel qu'il était et tu recommences la procédure.

Et ça nécessite vraiment une distinction artificielle entre logiciels de base et logiciels supplémentaires ?

Oui.

L'objectif est d'améliorer aussi la robustesse, la sécurité et la fiabilité.
Si tu mets trop de composants dans le système de base, tester dans le détail l'intégration c'est compliqué. Plus de risques qu'il y ait des problèmes profonds qui peuvent compromettre le démarrage de la machine, processus de mises à jour plus lentes car rebaser avec des application en plus c'est lent.

L'objectif est qu'un maximum d'applications soient distribuées via Snap ou Flatpak dans ce modèle. Plus de sécurité grâce à l'isolation logicielle mais aussi plus de flexibilité car si tu souhaites avoir Firefox beta + Firefox stable en même temps sur ta machine c'est facile. Si tu veux le dernier LibreOffice également, tu ne dépends plus uniquement du cycle de ta distribution qui est une contrainte pénible pour beaucoup d'utilisateurs.

La mise à jour d'un logiciels, c'est du remplacement de fichiers, et ça se fait très bien en fonctionnement. Pas en réécrivant directement les fichiers, évidemment, mais en les installant avec un nouveau nom puis en retirant les anciens et en renommant les nouveaux.

Cela paraît simple, mais en vrai ça ne fonctionne pas toujours aussi bien. Car là tu décris le cas idéal. Le cas le plus courant mais il est illusoire de croire que les soucis n'arrivent jamais.

En pratique ce que tu décris se fait déjà, mais il faut voir les problèmes qui peuvent survenir.

Que se passe-t-il si tu as une coupure de courant ou un crash au milieu des opérations ? Pour l'avoir expérimenté, ton système peut être dans un état irrécupérable car tu as des fichiers à jour, d'autres pas pour un paquet, tu as un paquet à jour mais ses dépendances (ou ce qui en dépendent) qui ne le sont pas, la BDD RPM qui est dans un état incohérent, etc.

Une mise à jour implique des scripts notamment de conversions de fichiers, de relance de services et autres et parfois pas de bol il y a un problème ou un conflit avec l'usage normal de la machine et hop pépin.

Ou tu démarres une application alors que certains fichiers sont à jour et pas les autres, ou qu'un paquet est à jour et pas sa dépendance et tu peux avoir des crashes ou bogues bizarres.

Ce n'est pas un hasard si l'industrie migre vers ce genre de conceptions. Dans l'embarqué cela se fait, sur les téléphones cela se fait, Windows le fait, GNOME Logiciels le fait, les systèmes atomiques le font, etc. C'est pour cette raison, pour couvrir correctement les cas où il y a des soucis potentiels.

Le dernière point est très intéressant, en revanche, pour les deux premiers, j'ai dû louper le moment où le fonctionnement à la Windows, où il faut redémarrer pour appliquer des mises à jour, avait commencé à être considéré un modèle.

Alors il y a des différences avec Windows en fait.

Tout d'abord c'est juste la base du système qui est concernée. Noyau, libc, systemd, etc. C'est la couche 0 du modèle d'un système atomique qui répond à ce critère. Cela ne touche pas le reste. Donc à priori ce n'est pas tous les jours que tu auras un tel changement.

D'autre part, la mise à jour fonctionne par état. En gros c'est comme "git" pour le code d'un projet, la mise à jour est juste un rebase à partir d'une branche spécifique. Le rebase se fait lorsque le système tourne normalement. Le redémarrage ne sert qu'à changer le commit de référence pour exécuter le système. En gros au redémarrage c'est quasiment instantanée, contrairement à Windows où ça prend du temps. Car la partie longue aura été faite quand l'ordinateur est utilisé normalement.

Avec ce fonctionnement, comme cela a été expliqué, l'avantage c'est que de revenir en arrière est fiable et tout aussi rapide si c'est nécessaire. Cela peut même se faire automatiquement si la machine est incapable de booter entièrement avec le nouvel état du système.

Enfin, oui l'approche de Windows reste théoriquement une bonne approche malgré tout. Des bogues qui arrivent et qui sont difficiles à corriger ou à identifier car on met à jour lorsque que le système tourne, cela arrive même sous Linux. Et si ton système crashe en pleine mise à jour pour X ou Y raisons, les problèmes peuvent vite s'accumuler. Appliquer les mises à jour quand le système est dans un environnement minimaliste réduit ces problèmes, en terme de fiabilité c'est mieux quoiqu'on en pense.

L'avantage ici c'est que la partie minimale du système nécessite une telle approche tout en restant fiable et le redémarrage reste une opération très rapide ce qui limite l'inconvénient de Windows.

Bien sûr, mais ce que je mentionne c'est qu'on n'a pas la preuve non plus que Meta sait y accéder à ces conversations.

Et qui si on en avait une preuve sérieuse, cela mériterait clairement une communication de la part de celui qui a une telle preuve sous la main.

Sauf que Whatsapp fait du chiffrement de bout en bout.

Les autres services de Facebook et Instagram ne le font pas et peuvent en effet être déchiffrés par Meta pour faire ce qu'ils veulent ce qui concerne des milliards de personnes depuis 2007 effectivement.

Ton lien ne parle pas spécifiquement de Whatsapp, si on a des preuves que Meta peut lire des conversations Whatsapp sans effort, ça mériterait une publication.

je m'interroge sur les fanfaronnade européenne la dessus, et du partage du lien vers cela qd bien même il s'agit d'un journal, dans la loi il n'y a pas écrit sauf les journaux.

Définir conversation privée alors que c'est manifestement un groupe de travail gouvernemental étranger dont la publication a été autorisée par le président des USA lui même car ce n'est pas un document classé secret défense. C'est pour ça que le journaliste américain l'a fait, car il en avait le droit, et de fait comme c'est public il n'y a aucune raison que la presse ne puisse pas relayer.

Par ailleurs comme souvent en droit, il y a des contradictions. La presse a aussi des libertés pour permettre de relayer ou de dénoncer des affaires d'intérêts publics. Pourtant cette liberté essentielle est nécessairement contraire à d'autres dispositions légales. Et cela ne pose pas un problème.

Enfin, la fuite à l'origine est purement américaine (discussions impliquant des américains, sur le territoire américains et publié par un journal américain par un journaliste américain), c'est donc le droit américain qui est d'application et pas le droit français. Le droit américain n'a pas le RGPD et le journaliste a eu l'accord officiel de le faire. Donc depuis cela n'a plus rien de privé car cela a été légalement publié. Puis je croyais que la liberté d'expression absolue était une belle valeur américaine au demeurant.

Bref, il n'y a aucune raison pour que ton commentaire soit pertinent ici. Mais étant données tes commentaires ici je me demande si cela n'est pas juste une réaction par rapport à tes convictions politiques.

Juste que répondre sur quelques requêtes qui ne respectent pas le robots.txt ne me semble pas être une bonne défense à l'heure actuelle, même si j’aimerai que ce soit le cas, et qu'on remette un peu d'ordre dans ce far west de l'entrainement des IA.

Tu parles de l'heure actuelle et je suis d'accord avec toi.

Personnellement je pensais adapter la loi pour couvrir notamment le premier point. Cela ne me semble pas insurmontable.

Après le site tu le mets bien à disposition du public, donc en quoi une requête d'un outil serait moins légitime (point de vue légal) que celle d'un autre utilisateur? Après je parle bien d'une requête, et pas d'une armée mal codée qui relis les pages encore et encore alors qu'il n'y a aucune modification dessus.

On peut attaquer l'usage plutôt que la requête en elle même.

L'objectif est de collecter de l'info pour en faire quelque chose. Un service autour d'un LLM, l'apprentissage du LLM, ou alimenter la BDD d'un moteur de recherche. On pourrait arguer que le propriétaire du serveur ne souhaite pas que le contenu certes public puisse alimenter ces services et que on devrait pouvoir respecter ce choix.

Ou de même attaquer non pas la requête individuelle qui a un coût dérisoire mais la conséquence d'un suivi agressif qui fait augmenter les coûts d'hébergement de manière significatives voire réduire les performances du système et peut s'apparenter de fait à un DDOS que le respect du souhait initial permettrait d'éviter.

La loi pourrait s'adapter autour de ça. Après tout on a bien des lois plus difficiles à gérer que ça dans le fond.

Merci pour la contribution en tout cas. :)

hash(id_compte+sel_du_site+mdp)

Autant faire un sel par compte directement, ce qui est recommandé par ailleurs. Plus besoin de l'id du compte.

Cela ne contredit pas ce que je dis au contraire.

Avec cette information c'est très facile de savoir s'il y a beaucoup d'hommes qui achètent les tenues pour leur conjointe voire toute la famille, ou juste pour eux. Et de même dans l'autre sens.

En fonction de ce qui se fait, l'entreprise peut adapter sa communication, pour consolider son marché actuel ou tenter justement d'accueillir une autre clientèle.

Cela peut avoir un intérêt marketing aussi.

Si la majorité de tes clients sont des hommes ou des femmes, ça peut être intéressants pour eux de le savoir pour adapter leur communication notamment pour attirer une plus grande diversité de clients et savoir ce qui a marché dans leur stratégie actuelle concernant leur public cible du moment.

Cela ne m'étonnerait pas que les grosses boîtes le fassent plutôt dans cette optique que pour afficher le bon texte pour ton courrier.

La croisade anti-spyphone d'aujourd'hui me fait un peu penser à celle pro-linux d'il y a 15 ou 20 ans, et qui n'a jamais mené à rien.

Qu'il y ait une croisade basée sur des arguments sérieux, je ne pense pas que ce soit un soucis.

Dans la discussion autour des téléphones, notamment par l'auteur du lien mais on le voit dans les propos tenus dans les articles et ce genre de personnes en général, il y a un mélange des genres.

Beaucoup d'arguments ne sont pas contre le smartphone mais contre l'hyper connectivité. Pour avoir connu l'ère avant les smartphones, j'ai connu des gens hyper connectés avec leur téléphone portable à l'époque. Décrocher systématiquement en toute occasion, y rester 3h pour une discussion, lire / répondre au SMS dès qu'un message a été reçu, etc.

Si le soucis est celui là pour ces personnes, se passer du smartphone peut être une solution, mais la bonne solution peut être aussi d'en avoir un mais s'en servir selon ses propres besoins et envie. Couper les notification / mode avion / mode silencieux quand on en a besoin, ne pas répondre dans la minute, etc. Beaucoup de gens savent très bien le faire avec un smartphone et peuvent bénéficier des autres fonctions quand ils le souhaitent sans se priver.

Je trouve cela embêtant de faire un amalgame des deux sujets à chaque fois. On peut refuser légitimement d'avoir un tel objet si on veut, mais utiliser des arguments un peu bancal c'est à mon sens contre productif.