liberforce a écrit 4733 commentaires

J'ajoute packer pour la création d'images, Gitlab-CI et Jenkins pour l'intégration continue, et potentiellement AWS si on met des VM dans le cloud.

Open Source = logiciel libre…

Open Source, surtout avec les majuscules, c'est Open Source au sens de Open Source Initiative, qui dit à 99% la même chose que le logiciel libre sur le plan technique. La rhétorique autour du logiciel libre insiste plus sur les libertés de l'utilisateur, mais ces libertés n'ont pas pour but l'asservissement du mainteneur.

Ensuite, tu as des logiciels propriétaires qui sont très à l'écoute des demandes des utilisateurs, et des logiciels libres où une personne code pour ses propres besoins et si ça profite à d'autres c'est bien, mais ce n'est pas le but recherché. Les questions morales et politiques sont donc orthogonales à la liberté du logiciel. Les mots ont un sens, qu'il ne faut pas extrapoler.

Être plus honnête et gérer une communauté, ça c'est vraiment du « Logiciel Libre » pour moi.

https://yourlogicalfallacyis.com/fr/le-vrai-bon-ecossais

Note qu'ils ne savent pas écrire "depth" tout de même (zoome sur la première capture).

Pas d'accord. Le logiciel libre, c'est la licence, point barre.

La manière dont tu gères une communauté d'utilisateurs, c'est autre chose.

si on te montre 5 cartes et qu'il faut les compter, tu ne les appréhenderas pas d'un coup, mais tu feras d'un œil 3+2=5.

C'est ce que je me dis toujours quand je compte sur les 3+2 doigts de chacune de mes 1+1 mains.

Pour mettre en évidence des caractères, Vim + un set listchars ?

http://vimcasts.org/transcripts/1/en/

Pour le remplacement automatique, il y a peut être quelque chose à faire avec les abbréviations, mais ça n'a pas l'air simple pour ton exemple du tiret. Tu pourrais avec:

:abbreviate -- —

dire que tu remplaces deux tirets par un tiret long, mais cela demande donc une connaissance de l'utilateur. M'enfin s'il utilise vim il a déjà appris le plus gros :)

J'avais déjà vu ce genre de comparaison mais pour quelque chose de plus parlant je pense: parler en distance uniquement plutôt qu'en distance. C'était à un GUADEC je crois, mais je n'arrive plus à retrouver. Mais en gros tu avais des cercles concentriques sur un planisphère pour montrer la distance à parcourir pour aller chercher l'information (cette distance étant intuitivement liée au temps: plus c'est loin plus c'est long d'y aller).
Tu te retrouvais donc, comme toi, à accéder au cache sur un papier sur ton bureau, ou alors à devoir aller à l'autre bout du monde récupérer l'information.

Il y a aussi (précis mais pas assez visuel à cause des changements d'échelle je trouve) :

Douche comprise.

En fait ça ne marchera pas pour plusieurs raisons.

Raison n°1: le mauvais type de guillemet est utilisé

Il faut différencier (je pars du principe que tu as un clavier azerty):

• ` (backquote, AltGr+7 sur ton clavier)
• ' (guillemet simple, sur la touche 4 du clavier)
• " (guillemet double, sur la touche 3 du clavier)

Je n'aime pas le backquote (guillemet inversé) parce que quand on débute on ne voit pas la différence avec le guillemet simple. La notation $(commande) est équivalente à `commande` et plus compréhensible à mon sens.

Pour comprendre un peu mieux, je te conseille donc la lecture du Guide avancé d'écriture des scripts Bash, et notamment la partie sur les guillemets.

Raison n°2: les espaces servent de séparateur

Cette commande n'est pas valide:

ls..

Celle là oui:

ls ..

Raison n°3: man est ton ami (aka RTFM)

A quoi sert le xvzf dans un tar xvzf …

La commande man te donne des infos sur une commande. man tar te dira donc à quoi correspondent les lettres qui suivent (pour casses le suspense, ce sont des options, à toi de regarder le manuel pour savoir ce que fait la commande tar et à quoi correspondent ces options)

Conclusion

Il y a de fortes chances que tu te sois gourré en tapant ta première commande:

for i in 'ls..lesDonnees/*.val'

(au passage il manque aussi un slash).
Je ne pense pas me tromper en disant qu'il doit être écrit sur ton papier plutôt:

for i in `ls ../lesDonnees/*.val`

Tu devrais à présent voir les différences.

Ça fait déjà un mois qu'il est de retour:
https://lkml.org/lkml/2018/10/23/288

Idem, un coup de wget, pas de fichier .reg. Les fichiers en eux même sont juste des fichiers contenant des données aléatoires. Il y en a un seul qui contient la chaine "reg", et c'est par pur hasard. Donc on oublie le coup du fichier qui contient le lien vers le fichier .reg… Aucun fichier qui contient la chaîne "HKEY" non plus. Il y a 30 fichiers que "file" ne voit pas comme étant de l'HTML, et rien de lisible.

C'est un exo censé être facile ou bien la stéganographie est au programme ? ^{_^}

Si ces logiciels ont besoin d'un environnement à eux, mais que tu ne veux pas polluer ton shell avec leur environnement, alors fais juste un script qui sert de wrapper. Il chargera l'environnement de tes autres scripts avant de le appeller.

Si au contraire tu veux toujours avoir cet environnement dans ton shell courant, alors fais un source cao-scripts/environnement-logiciel dans ton $HOME/.bashrc.

Dans tous les cas, l'environnement et l'appel du programme final sont deux choses distinctes. Il faut les découpler, pour que n'importe qui puisse charger un environnement, potentiellement différent.

Et sinon, comment tu as atterri sur linuxfr si tu ne sais pas utiliser un moteur de recherche ?

Cette recherche:

https://www.google.com/search?q=python+tutoriel

T'aurait permis de trouver (entre autres) ceci:

https://openclassrooms.com/fr/courses/235344-apprenez-a-programmer-en-python

Arf, oui j'avais oublié cette limitation. Je n'utilise que des applis python sur la machine où j'ai fait la modification, et les dernières versions de Python 2.7 et Python >= 3.6 gèrent les chemins longs, du coup ça "just works". Mais rdiff-backup est libre (GPL-2.0-or-later), et, même si le recompiler ne doit pas être une partie de plaisir, le manifest peut être patché.

Voilà le patch pour Python 3.6, ça devrait être transposable:
https://hg.python.org/cpython/rev/26601191b368

La 1.2.8 (dernière stable) est disponible ici:
http://svn.savannah.nongnu.org/svn/rdiff-backup/tags/r1-2-8/rdiff-backup/

La 1.3.3 (version de développement) est disponible ici:
http://svn.savannah.nongnu.org/svn/rdiff-backup/tags/r1-3-3/rdiff-backup/

Sinon tu as un import git ici:
https://github.com/sol1/rdiff-backup

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.