wismerhill a écrit 2602 commentaires

Oui, par contre tu ne peux pas, à partir d'un profil donné, demander à ouvrir un lien dans un autre profil.
Il faut copier le lien et le coller dans une fenêtre de l'autre profil.

Konqueror existe toujours, il a été porté vers KDE framework 5.
Il n'a pas régressé, c'est le reste qui a continué d'évoluer.

Du coup, ce genre de jeu est vraiment plus adapté à un développement par une entreprise, qui propose une expérience à "consommer" (ce n'est pas un gros mot) en échange d'argent. Ce qui n'exclut pas que ce soit libre dans l'absolu évidemment.

Pourtant, j'en reviens à mon message initial, il y a de nombreux mods solo créés par des particuliers, qui sont parfois de grande qualité (dans ce cas ce sera fait par une petite équipe plutôt qu'une personne seule), et sont disponibles gratuitement (volontairement, pas par piratage).
Donc il y a des gens qui ont envie de faire ce genre de chose, que ce soit par passion, comme un défi, ou pour se faire une référence pour ensuite en faire son métier.

Donc je me demande, est-ce qu'aucun de ces FPS libres (à part les clones de doom) ne met à disposition l'infrastructure pour faire des campagnes solo?
Parce que forcément, s'ils ne font que du multi ça ne va pas attirer les gens qui seraient susceptibles de créer des campagnes solo.

Encore un FPS pour faire du multi-joueur.
N'y a-t-il donc personne dans le libre qui ait envie de réaliser des compagnes solo?

J'ai beaucoup joué aux FPS, mais le multi-joueur ne m'a jamais beaucoup attiré (trop répétitif).
Mon préféré reste halflife premier du nom, le mode solo original était très original avec plein de styles différents et des séquences scénarisées bien pensées.

Il y a quelque années j'ai fait une "rechute", j'ai d'abord refait toute la compagne originale de halflife et les extensions officielles, puis je suis allé voir dans les mods solo disponible en ligne. Il y en a plein qui avaient été développé entre temps, dont certains de très grande qualité (égale, voir supérieure, au jeu original). Et tout ces mods avaient été développés par des amateurs, et mis à disposition gratuitement.

Pourquoi ne voit-on pas ça avec des FPS libres?
Est-ce qu'ils manquent d'outils de développement de niveau intermédiaire, genre éditeurs de niveaux avec possibilité de scriptage, destinés à des non programmeurs?

Les traitements de texte et tableurs (en tout cas libreoffice, et d'autres aussi probablement) ne mettent pas à jour le fichier, mais enregistrent dans un nouveau fichier, puis renomment atomiquement en remplaçant l'ancien fichier. Donc pas de CoW puisque ce sont de nouveaux fichiers à chaque fois.
Cette façon de faire évite, en cas de plantage, de se retrouver avec un fichier corrompu (la copie en cours d'enregistrement le sera probablement, mais l'ancien fichier n'aura pas encore été écrasé), mais ça ne préserve pas les droits des fichiers (en particulier si on avait le droit d'écriture sans être propriétaire du fichier).

j'ai téléchargé et éxecuté parted
dans parted j'ai fais resizepart 1
ensuite quand il m'a demandé la taille j'ai mis 42 GB
et j'ai quitté parted et rebooté.
Après reboot j'ai fais resize2fs -p /dev/sda1 et quand il m'a demandé la nouvelle taille j'ai entré 40G.

????

Si tu voulais une partition de 40GiO, il suffisait de le demander directement à parted.
As-tu réduit la taille de la partition des 2GiO devenus inutiles après avoir réduit le FS de 42GiO à 40GiO?

sda2 est la partition étendue, sda5 se trouvait dedans.
Je ne savais pas que fdisk acceptait de travailler directement avec une partition étendue, mais pour la supprimer elle-même, c'est sda qu'il faut modifier, et ensuite redimensionner sda1.

Mais comme tu ne t'y connais pas trop, tu ferais mieux d'utiliser un outil un peu plus haut niveau comme gparted (par exemple via system rescue CD) qui peut s'occuper simultanément du redimensionnement de la partition et du système de fichiers.

Le vmdk, c'est un disque virtuel, qui correspond donc à ton sda, vu les informations que tu donne.
Mais ce disque virtuel est partitionné, et ton FS se trouve dans une partition, il faut donc redimensionner aussi la partition, donc sda1 dans ton cas.

Le problème, c'est que tu as une deuxième partition après celle-là, sda2, qui contient elle-même sda5.
Comme sda5 n'est qu'une partition de swap, tu peux la supprimer, redimensionner sda1 et re-créer ta swap ensuite (il faut d'abord faire un swapoff pour qu'elle ne soit plus utilisée).
Une fois sda1 agrandie, resize2fs pourra faire son office.

Au passage, ça ne sert à rien de te compliquer la vie avec une partition étendue, le partitionnement MBR supporte 4 partitions primaires, donc s'il ne t'en faut que 2 fais-les simplement en primaires.

Et puis, tu es sur une VM, donc tu peux créer des disques virtuels de n'importe quelle taille, fais-en donc un petit juste pour la swap, ce sera beaucoup plus facile de les gérer.

Heu, si les paquets en question avaient un équivalent dans mageia 6, ils devraient être mis à jour par un simple urpmi --auto-select (si tu as configuré les dépôts complets), ou alors il te dira pourquoi il ne peut pas le faire.

Les paquets qui restent sont vraisemblablement des choses qui n'existent plus dans mageia 6.

Pour les libs, il y a effectivement souvent des choses qui trainent, parce que le nom du paquet inclus généralement la version, pour permettre d'en avoir plusieurs d'installées en parallèle, et donc conserver des programmes qui dépendent des anciennes.

Si tu veux nettoyer sans risque de casser quelque chose (du moins si tu n'a rien installé manuellement), la commande urpmi_rpm-find-leaves et plus adaptée, elle te liste les paquets dont rien ne dépend.
Donc tu fais un

urpmi_rpm-find-leaves |grep ^lib

pour trouver toutes les libs inutiles (attention, pas de suppression automatique de la liste car ça inclura aussi libre office, et quelques autres choses dont le nom commence par lib, comme libalsa-plugins).
Tu itère l'opération quelques fois car les libs dépendent souvent les unes des autres en cascade.

Après, s'il te reste encore des paquets mga[345], c'est que ce sont des programmes (ou autre) qui n'existent plus dans mga6 mais n'ont pas été pour autant retirés de force (via task-obsolete), et c'est à toi de décider si tu veux les conserver.

Janvier 2019 c'est la date (prévue) de fin du support de mageia 6, soit 18 mois après sa sortie.
Mais le cycle de release normal de mageia c'est normalement 9 mois, donc si tout se passe bien la mageia 7 devrait sortir en avril 2018.
Mais si un nouveau gros problème devait se présenter, ils ont déjà prévu que le support de mageia 6 pourrait être étendu, pour durer au moins trois mois après la sortie de la 7. (comme c'est le cas de la 5 qui aura été supportée beaucoup plus longtemps que les 18 mois initialement prévus)

Ça gaspille de la place horizontale.

Par exemple, si tu as un programme qui ouvre un fichier en écriture, se place à l'offset 1730, change 5 octets puis ferme le fichier, la couche d'abstraction au-dessus de FTP doit télécharger tout le fichier (avant de rendre la main au programme!), et une fois l'enregistrement fait il doit renvoyer le fichier.
Et faire un lock sur un fichier ne fonctionne probablement pas (la couche d'abstraction le simule peut-être en local, mais ça n'a aucune incidence sur le serveur distant).

Il faut plutôt voit ça comme un moyen de transférer les fichiers sans devoir utiliser un client spécifique, mais pas comme un espace dans lequel on peut travailler directement (ce que des vrai systèmes de fichier réseau permettent).

J'ai vu des managers d'équipes de dev qui n'y connaissaient pas grand chose et c'est pire que tout.

Ce n'est pas un problème s'il en a conscience et prend conseil auprès de ses subordonnés compétents.

Malheureusement, on a plus de chances de tomber dans l'Effet_Dunning-Kruger.

Je suppose qu'il n'y a sur ce disque dur que des données sans importances.
Car depuis la dernière fois que tu as vérifié la surface, il y a peut-être de nouveaux secteurs qui sont devenus défectueux, et la prochaine fois que tu accèdera aux fichiers concernés ça plantera.

Oui, on parle de biboumi, et oui effectivement il n’est pas dans stable (mais il reste quand meme en version 4.x, je ne sais pas trop pourquoi du coup, vu que la version 5.0 est sortie et est vachement mieux).

Ces derniers mois, l'objectif de debian était de corriger les problèmes pour sortir debian 9 justement.
Ça implique que sid était gelé et que les mainteneurs ne mettaient à jour les paquets que pour corriger des problèmes connus.
Donc, forcément un paquet qui n'est pas destiné à être inclus dans la stable en préparation ne va recevoir beaucoup d'attentions.

Vu qu'il utilise explicitement bash (pas besoin d'être compatible bourne shell), autant utiliser la syntaxe

if [[ $result == 1 ]] ;then

comme [[ est une construction du langage (contrairement à [ qui est une commande), il n'a pas ce problème.

Ta méthode fonctionne merci. Avec l'ajout de >/dev/null 2>&1 on peut aussi supprimer la phrase de réponse sans apporter de bug :)

Ou alors on demande à mountpoint de ne rien afficher avec son option --quiet

Je ne connais pas de manière, avec Ansible, pour appeler 7 plays en une seule commande aussi simple, sauf à faire un playbook pour chaque programme, puis utiliser les rôles, etc etc. Donc au lieu d'un seul script, j'aurais plus de 50 petits fichiers…

Juste pour répondre à cette remarque, et sans impliquer que tu devrais changer ta façon de faire.

Ce genre de chose se fait typiquement avec des tags.
Tu fais un playbook avec toutes les actions à appliquer, et tu applique des tags sur les différentes actions selon, ce à quoi elles s'appliquent. Si une action particulière est toujours nécessaire (par exemple parce qu'elle récupère des informations qui sont utilisées à plusieurs endroits), plutôt que de devoir lui appliquer tous les tags, il y a un tag spécial always pour toujours l'exécuter.
Ensuite, tu peux exécuter ansible-playbook avec l'option -t (--tags) pour n'exécuter que les actions qui correspondent à ce(s) tag(s). Il y a aussi une option --skip-tags pour exclure selon d'autres tags.

Note que ça peut aussi fonctionner de façon hybride, la commande de base ansible permet d'exécuter une unique action, elle peut donc être utilisée dans un script (et appliquée à localhost) pour profiter des fonctionnalités de certains modules complexes, et scripter d'autres choses qui seraient de toute façon compliquées à faire dans ansible.

Avec keychain (mais c'est relativement facile à faire manuellement, keychain est lui-même un script shell) les informations sont stockées dans des fichiers ~/.keychain/-{csh,fish,sh} et il suffit, dans ton script, de sourcer celui qui convient pour utiliser l'agent qui aura été démarré par keychain à la connexion.

Le wikipedia français va dans ton sens, par contre la version anglaise est moins catégorique:
https://en.wikipedia.org/wiki/Trim_(computing)#Operation
Le dernier paragraphe indique que les données ne sont pas forcément physiquement effacées des cellules flash, et donc potentiellement récupérables avec du matériel adapté.

Vu que les SSD fonctionnent par blocs nettement plus gros que les 4kiO habituels des FS, ce serait contre-productif d'essayer d'effacer un bloc logique dès qu'on le trim, il vaut mieux au contraire retenir les blocs "trimmés", et attendre d'avoir un bloc physique complet pour pouvoir l'effacer d'un coup.

De la même façon, les SSD utilisent le trim, qui effacent carrément les données des cellules.

Non, ou en tout cas pas obligatoirement.
Le trim (appelé discard sous linux) permet au système de dire au SSD que certains secteurs ne sont plus utilisé (il n'y a plus de donnée utile dedans) et que le SSD peut donc les ré-utiliser la prochaine fois qu'il fera une écriture (en général les SSD ne ré-écrivent pas au même endroit, pour répartir l'usure sur toutes les cellules, ce qui est un peu gênant pour l'effacement sécurisé façon shred).
S'il n'y a pas eu de ré-écriture, les données effacées sont probablement encore dans les cellules, mais avec le wear leveling compliqué qui est mis en place ça doit être très compliqué de retrouver ses jeunes.

Mais de toute façon, le sujet d'origine est un SSD qui a cessé de fonctionné, ce sont donc les données qui y étaient encore stockées, celles sur lesquelles on n'a pas fait de trim, qu'il voudrait récupérer.

Si par « var_a m'est passée par un appel à mon playbook » tu veux dire que la variable est passée par la ligne de commande ansible-playbook (extra vars), alors tu ne peux rien faire, celles-là ont la priorité maximum.
Si tu veux dire qu'elle est définie directement dans le playbook (play vars), elles ont également une priorité supérieure aux variables venant de l'inventaire.
Voir la documentation d'ansible pour l'ordre de précédence des variables
http://docs.ansible.com/ansible/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable

Ah, j'avais compris à l'envers, je croyais que tu ne pouvais pas modifier les variables des hosts et était obligé de les re-définir dans le playbook.
Alors je ne vois pas bien le problème, met directement la bonne valeur puisque tu controlle la définition 'origine des variables.

Sans avoir vérifié dans le code d'ansible, je suppose que c'est un effet de bord de la façon dont sont implémentés les facts d'ansible.
Il ne faut probablement pas voir ça comme une affectation de variable, qui ferait appel à son ancienne valeur, mais à une re-définition de la valeur, l'ancienne valeur n'étant plus disponible tu te retrouve avec une définition récursive qu'il ne peut pas résoudre.

Mais tu ne dis pas à quel endroit tu essaie de re-définir cette variable.
Est-ce dans une action set_facts?
Ou peut-être dans une section vars d'une action, ou d'un block?

Au passage, si ta variable booleen est déjà un … booléen, tu peux résumé ton test à "not booleen" (avec quand même de filtre default si la variable n'est pas définie pour tous les hosts), et en inversant le if on évite la négation.

Au pire, si tu as vraiment besoin de re-définir la variable var_a, ça peut probablement se faire en deux temps:

- set_fact:
    var_a_bis: "{{var_a if booleen|default(true) else var_b}}"
- set_fact:
    var_a: "{{var_a_bis}}"

Je n'ai pas testé, mais comme les actions s'exécutent séquentiellement, ça devrait le faire.

• on n'a aucune idée de ce que fait le bash en question (un .deb est plus facile à évaluer),

Heu, un deb ou un rpm ont aussi des script des pré et post (dés)installation, et ce n'est même pas évident à priori, il faut aller chercher dans les méta-données du paquet pour voir s'il y en a et ce qu'ils fonts.