liberforce a écrit 4744 commentaires

argh, c'est activate.bat, pas activate.cmd.

(en ce moment j'utilise les "marques-pages dynamiques" de firefox)

Profites-en bien, il me semble qu'ils vivent leurs dernières heures.

We offer single-file binaries that do not require installing anything - you can just run them on these platforms:

• Linux
• Mac OS X
• FreeBSD
• OpenBSD and NetBSD (no xattrs/ACLs support or binaries yet)
• Cygwin (experimental, no binaries yet)
• Linux Subsystem of Windows 10 (experimental)

"Pas de binaire tout-en-un pour Windows" c'est différent de "pas de version Windows". borgbackup est disponible sur PyPI, donc tu peux installer chocolatey par exemple, puis taper dans un shell Windows:

choco install python3             # il faut répondre "yes" pour autoriser l'exécution des scripts

                                  # Ici, il faudra peut être fermer et réouvrir le shell,
                                  # ou faire un "reloadenv" pour avoir les variables d'environnement
                                  # python

virtualenv backup-tools           # On va faire propre et créer un environnement virtuel
backup-tools\Scripts\activate.cmd # On rentre dans l'environnement virtuel
pip install borgbackup            # On installe borgbackup

On peut autoriser les chemins supérieurs à 256 caractères depuis (au moins) Windows 10 et Windows Server 2016.
Tu as une clé de registre à activer: https://stackoverflow.com/a/52007527/518853

Tu as donc peut être une chance que rdiff-backup fonctionne ;).

Tu as jeté un coup d'oeil à conan ?

Le lien vers les release notes pointe sur la racine de toutes les release notes.
Là on veut f29, pour avoir quelque chose de stable dans le temps il vaudrait donc mieux pointer vers https://docs.fedoraproject.org/fr-FR/fedora/f29/release-notes/

Je vois le problème, mais je ne sais pas si i786 c'est "la" solution. En tout cas, si déjà sur les mécanisme d'upgrade on vérifiait que le matériel que tu t'apprêtes à mettre à jour est toujours géré par la version n+1 de la distrib, ce serait déjà autant de personnes en moins qui flingueraient leur config pour rien.

Et le bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1592212

Et la proposition à son origine:
https://fedoraproject.org/wiki/Changes/Update_i686_architectural_baseline_to_include_SSE2

Le constat pour Fedora est donc:

• le kernel n'est plus stable parce que pas assez testé sur 32-bits
• les paquets 32 bits sont utilisés surtout en parallèle des paquets 64 bits sur des systèmes 64 bits

Donc pour faire du 32 bits, ils se basent sur le jeu d'instruction 32 bits que les premiers CPU 64 bits comprenaient. Ensuite des gens mettent à jour des vieilles machines, et paf le chat.

Voilà le commit qui active SSE2 par défaut pour i686:
https://src.fedoraproject.org/rpms/redhat-rpm-config/c/a5c98437e2aabe7a75fc13099a41ed3306587401

Au passage les iso Mageia 6 sont en "i586". Le guide d'empaquetage contient ceci:

Vous aurez aussi besoin d'ajouter deux fichiers de configuration dans votre répertoire de travail :

.rpmrc

buildarchtranslate: i386: i586
buildarchtranslate: i486: i586
buildarchtranslate: i586: i586
buildarchtranslate: i686: i586

Ça n'aide pas à la compréhension.

Ensuite, que ce soit Fedora, Mageia ou autre, i*86 c'est trop "grosse maille". Si le système te propose une mise à jour que tu acceptes sans vérifier systématiquement à chaque release que ton CPU est bien toujours géré, bin tu peux faire la mise à jour et te retrouver avec un système potentiellement cassé.

Super, merci !

Si quelqu'un à un lien pour Mageia, je suis preneur. On m'a orienté vers le fichier boot/config-{version} ou la commande rpm --eval %configure mais il y a forcément un rpmrc équivalent chez mageia, mais je ne sais pas où il se trouve non plus.

Alors soyons clairs:

• je ne demande pas aux distribs de compiler sans SSE2, les nouvelles machines doivent pouvoir tirer partie des optimisations
• en pratique, je n'ai eu des soucis qu'avec 2 composants utilisant réellement SSE2 (flash et libflac), "tout compiler pour quelques machines perdues" est donc hors de propos

Cependant, par expérience, ces machines sont encore utilisables (la mienne en tout cas). J'ai racheté un portable plus récent, mais mon vieux PC fixe est le seul à avoir un lecteur CD. J'ai un autre vieux PC récupéré, à base de CPU intel mais lui c'est la carte graphique qui ne gère pas GNOME 3. Même problème, les pre-requis minimum, sont "flous". En gros pour savoir, faut essayer.

Je suis capable de recompiler les programmes qui posent problème. Mais les distribs ne communiquent pas trop sur les pré-requis matériels, changent plus ou moins silencieusement des flags de compilation importants, tout en conservant la même appellation "i686" qui a toujours fait fonctionner nos vieilles machines.

Quand tu casses la compatibilité binaire d'un logiciel, une bonne pratique est de changer de version majeure. Là tu romps la compatibilité mais tu t'appelles toujours i686, et les gens passent du temps à déboguer parce que ça a toujours fonctionné chez eux par le passé. Cela devrait être possible de déduire quelles architectures matérielles exactement sont gérées à partir des flags de compilation. Il faudrait juste les mettre plus en avant plutôt que promouvoir un "i686" qui n'a plus beaucoup de sens.

Le problème n'est pas que là. Ce qui me dérance c'est plutôt que les distribs décident de ne plus prendre plus en charge SSE2, continuent à faire des paquets i686, mais ne communiquent pas sur le fait que ça ne marchera plus pour certaines personnes. L'utilisateur final ne sait pas non plus à partir de quelle version de distrib exactement ces architectures ne sont plus gérées (ou alors l'information m'a échappé).

Pourtant en pratique, j'ai eu le problème avec très peu d'applications: d'abord le plugin flash (mais lui a l'excuse d'être propriétaire), puis libflac 1 ou 2 ans plus tard.

Ah, c'était dans libflac le problème. Un autre soucis c'est de savoir avec quels flags d'architecture sont compilés les distros, pour pouvoir savoir chaque distrib est vraiment compatible.

On tombe alors dans les distributions pour ordinosaure… C'est du matériel avec 1,5 Go de RAM, capable de faire tourner un GNOME 3. Ça ferait certes une occasion d'essayer une SliTaz, mais c'est pas un 486 non plus…

Ou change de machine.

On ne devrait pas avoir à changer de hardware pour des problèmes purement logiciels… Développement durable, tout ça…

Je me suis fait la même remarque. J'ai un Athlon XP 3000+ (barton) acheté en 2004 je crois. Je me suis rendu compte de problèmes avec SSE2 quand j'ai tenté de ripper mes CD audio avec sound-juicer (sous Mageia 6, le problème n'est pas que chez Fedora). La seule solution a pour moi été de le recompiler en désactivant la gestion SSE2. Cela peut être un peu pénible, mais c'est le seul logiciel avec lequel j'avais eu ce problème. Je n'avais pas eu le soucis avec Firefox, mais j'utilise moins cet ordi depuis cette année. Après c'est sûr que rebuilder Firefox, c'est pas ce qu'il y a de plus pratique…

En cherchant un peu je suis tombé sur ce thread: https://superuser.com/a/1254953
On y pointe cet outil en Rust, elfx86ets, permettant de détecter le jeu d'instructions utilisé par un binaire (et donc potentiellement trouver les binaires à problème selon son architecture).

Par ailleurs, il a été constaté dans la partie de la base de données dédiée à la gestion des étudiants, des commentaires tels que : diagnostiqué de plusieurs maladies graves […] ou très lourdement endetté […].

Sûrement un coup des syndicalistes :p. Sérieusement, la lecture des manquements vaut effectivement le coup d'oeil. Pour une école qui enseigne l'informatique, ça craint du boudin vu le nombre d'infractions.

La délégation a enfin été informée que les postes de travail des agents de sécurité qui ont accès au dispositif de vidéosurveillance est protégé par un mot de passe composé de 5 caractère alphanumériques.

De l'importance de la ponctuation…

C'est l'heure de manger, les enfants.

vs

C'est l'heure de manger les enfants.

On peut s'occuper d'un autre problème du même genre maintenant, les motards. Ils se regroupent le dimanche, boivent, font un boucan d'enfer et ce sont de vrais dangers publics sur la route. Interdisons la moto !

Je propose qu'on rajoute juste un peu plus de loups.

Je manipule de moins en moins des fichiers systèmes, alors ceci ne m'évoquait plus grand chose:

root::16431:0:99999:7:::


Il faut commencer par comparer avec la ligne existance avec sudo grep root /etc/shadow. Pour comprendre un peu mieux je rajoute un extrait de man shadow. C'est le 2ème champ vide (plutôt qu'avec un point d'exclamation, en tout cas sur ma vieille Ubuntu) qui ouvre la porte:

mot de passe chiffré
           Consultez crypt(3) pour plus d'informations sur le traitement de cette chaîne.

           Si le champ du mot de passe contient une chaîne qui ne peut pas être un résultat valable de crypt(3), par exemple si elle contient les caractères ! ou *, alors l'utilisateur ne pourra pas utiliser
           son mot de passe UNIX pour se connecter (mais il se peut que l'utilisateur puisse se connecter au système par d'autres moyens).

           Ce champ peut être vide. Dans ce cas aucun mot de passe n'est nécessaire pour s'authentifier avec l'identifiant de connexion indiqué. Cependant, certaines applications qui lisent le fichier
           /etc/shadow peuvent n'autoriser aucun accès si le mot de passe est vide.

           Un champ de mot de passe qui commence avec un point d'exclamation indique que le mot de passe est bloqué. Les caractères restants sur la ligne représentent le champ de mot de passe avant que le
           mot de passe n'ait été bloqué.

Galaxy J5 ici, et je compte bien le faire durer aussi longtemps que possible, c'est pas comme si les réserves de terres rares étaient infinies. Je n'utilise que Firefox, donc je trouve aussi la question de savoir si Firefox continuera de tourner avec d'anciennes version d'Android pertinente…

Je t'avoue que j'avais vu l'article circuler et pas vu sa date. Mais comme toi je vois régulièrement des services qui proposent ce genre de méthode d'installation, et pas vraiment d'avertissement. Je ne sais pas s'il y a eu des modifications dans curl mais je ne vois pas ce que ça changerait: c'est le serveur web qui est malicieux, et altèrerait le contenu du ficher. Je ne vois pas trop comment wget ou curl pourraient détecter cela.

La situation sur exFAT notamment est confirmée notamment par Bradley Khun de la Software Freedom Conservancy.

M'enfin le meilleur endroit pour en discuter reste le journal Vers une fin de la guerre des brevets logiciels ?