Adrien Dorsaz a écrit 889 commentaires

Avec Xfce, tu utilises quel gestionnaire de fenêtre ?

Si tu utilises le manager xfwm4, tu pourrais suivre le wiki d'ArchLinux. Apparemment, ils appellent ça "window tiling".

Si tu utilises "mutter" de GNOME, tu peux désactiver cette option nommée "edge-tiling" avec dconf-editor (le chemin exact c'est "/org/gnome/mutter/edge-tiling"). Aux utilisateurs de GNOME 3, gnome-shell prend aussi en compte ce paramètre (car il utilise libmutter).

Edit:
"metacity" de GNOME 2 a le même genre d'option sous "/org/gnome/metacity/edge-tiling".

Gnome-Shell peut aussi utiliser son propre paramètre avec "/org/gnome/shell/overrides/edge-tiling".

La recherche de "tiling" avec dconf-editor fonctionne très bien :)

Néanmoins la dernière phrase de son commentaire est très importante et a été laissé de côté dans ton article si je me souviens bien:

La CLI de git explique beaucoup de choses : ce que tu dois/peux faire quand un merge n'est pas automatisable par exemple. Comment continuer le merge, abandonner le rebase…

Ce côté apprentissage de la cli de git est vraiment positif et manque souvent dans les GUI pour guider le développeur.

La gui est assez mauvaise pour l'apprentissage d'ailleurs: quand mes collègues bloqués me demandent quoi faire, je leur demande ce qu'ils veulent faire et je lance un git status qui explique souvent comment continuer/abandonner.

Un autre commentaire avait aussi souligné que la documentation en ligne de gît est aussi basée sur la CLI. La doc est aussi de mon point de vu plus intéressante pour comprendre plutôt que de faire des cliques au hasard.

Toutefois, la gui est plus pratique pour avoir une vision globale de son code. Également pour choisir les lignes de code à indexer, la souris est plus pratique. Au final, je trouve l'intégration de git dans vscode assez optimale : ce n'est pas une usine à gaz et ça me permet de faire les tâches courantes.

Exactement, et vu le commit qui a amené le flag et cette constante, j'ai l'impression que c'est une limite arbitraire (mais tout de même assez raisonnable).

Je me demande si tu pourrais compiler un noyau avec une constante plus élevée (disons 512) et espérer que tout fonctionne encore ?

D'après ce post très détaillé de Stack Overflow, par défaut, le nombre de partition max pour un système GPT est de 255 (pour les disques usuels si j'ai bien compris le flag).

Dans l'autre sens c'est plus difficile de récupérer le hash.

Si tu mets le hash à la fin, donc après le numéro de version ici, tu peux lire de droite à gauche les noms. Ainsi tu sais qu'il faut partir de la fin du nom de fichier et remonter de x caractères pour retrouver le hash.

C'est beaucoup plus propre pour les utilisateurs et je pense que ça ne devrait pas trop impacter les performances.

c’est une dépendance à du code non-libre qu’on souhaiter boycotter, etc

Dans ce cas, aucun fork de youtube-dl ne te sera utile: dès que tu dépends d'une de ces plateformes (youtube, dailymotion…), tu dépends de fait de leur code privateur. C'est un non-sens d'espérer pouvoir profiter de ces plateformes avec uniquement du logiciel libre (car c'est la plateforme qui décide comment elle doit être utilisée).

En fait, pour bien boycotter ces plateformes privatrices, il faut proposer une alternative aux plateformes elles-mêmes. Actuellement, pour les vidéos, il me semble que Peertube est la plateforme qui pourrait bien changer la donne.

Hello,

Il me semble que GCC ne "cache" pas les constantes string dans le binaire.

Tu dois pouvoir vérifier avec ton éditeur de texte favoris ou avec la commande strings ton_binaire.

cf: https://github.com/linuxfrorg/linuxfr.org/pull/263

Simplement parce que je pensais que les scripts Ansible seraient bientôt disponibles ^^

Mais vu comme le temps passe vite, je vais faire un rebase et un PR. Merci pour le relancement du sujet.

Hello,

Pour t'aider dans la mise en place de ton environnement, j'ai écris un fichier "INSTALL.md" qui explique comment installer LinuxFr sur Debian Stretch.

Pour la piste du template, ça à l'aire juste, je commencerais par là aussi :)

Tu verras, Rails est sympa, il définit un environnement de travail assez chouette avec un ORM qui se base sur les models pour gérer la base de donnée et sur une approche MVC classique gérée par le serveur bin/rails.

Avec Rails, pas mal de choses sont définies de manières implicites. Pour ce bug, ça ne devrait pas être nécessaire, mais, si tu veux mieux comprendre le fonctionnement de Rails, leur tutoriel est un très bon début :)

Tu peux faire des PRs pour tout ce que tu veux et dans ce cas, ça semble pertinent comme ajout.

Il me semble que, même sans entrée dans le suivi, tu peux faire des PRs. L'entrée dans le suivi permet d'avoir les avis des autres et voir si c'est pertinent pour le site. Je pense que des corrections du style, une mise à jour du Readme, n'a pas forcément besoin d'une entrée de suivi.

Bonne découverte !

Hello,

Si je me souviens bien des longs débats Snap vs Flatpak vs Appimage, Canonical a choisi par design de ne permettre d'utiliser qu'une seule source de snaps (snapcraft.io).

Et c'est justement un des points qui différencie Flatpak. Flatpak a décidé par design le contraire: n'importe qui peut créer son propre serveur flatpak et l'utiliser.

Maintenant Canonical vient de casser le système de miroir de Debian par ce package qui dépend de snapcraft.io (c'est le cas depuis 1 ou 2 versions je crois).

Je pense que le plus simple pour continuer d'utiliser les mirroirs, c'est d'utiliser Debian. En effet, Debian n'a pas d'intérêt à imposer Snap via ses paquets .deb.

PS: pour plus d'informations, notamment l'avis de Linux Mint: https://linuxfr.org/users/ps12r/journaux/canonical-refait-cavalier-seul-et-annonce-une-nouvelle-boutique-logicielle-centree-sur-snap

Wow, c'est effectivement étonnant, je ne pensais pas que LibreOffice faisait des PDFs non-standards avec cette option.

Je trouve aussi que l'argumentation de l'utilisateur kurt.pfeifle est vraiment mauvaise: avec ce genre de discours, on ne corrige jamais aucun bug… genre "pas vu, pas pris".

Par contre, je pense que ça serait intéressant d'ajouter un commentaire pour expliquer que, si LibreOffice corrige ce bug, ça sera utile pour pouvoir inclure facilement des factur-x.

Hello,

Au sommet denode.rb, il y a une note qui dit que le user peut être NULL:

class Node < ActiveRecord::Base
  belongs_to :user     # can be NULL

J'imagine que ça peut être pareille pour les commentaires.

C'est peut-être des votes sur des contenus/commentaires de comptes supprimés ?

Une piste pour comprendre la production serait de lancer des requêtes SQL du style:

select count(1), DATE(created_at) as creation_date
from nodes
where user_id is NULL
and score <> 0
and creation_date > DATE_SUB(CUR_DATE(),INTERVAL 1 MONTH)
order by creation_date desc;

select count(1), DATE(created_at)
from comments
where user_id is NULL
and score <> 0
and creation_date > DATE_SUB(CUR_DATE(),INTERVAL 1 MONTH)
order by creation_date desc;

Dans le where, on peut ajuster la condition sur la date de création pour l'analyse.

Pour éviter d'avoir ces clés bizarres, on pourrait ajouter une condition à la fin des lignes que tu as trouvés (dans node.rb et comment.rb, ça devrait suffir):

unless self.user_id.nil?

Je ne sais pas si on est dans le même cas, mais LibreOffice est déjà capable d'inclure le fichier odt dans le PDF. C'est accessible via une option à cocher quand on utilise la fenêtre d'export

Il faudrait voir si l'odt est une pièce jointe du PDF, je ne sais pas…

Je me demande s'il parle de l'historique qui est en RAM et n'est pas encore enregistré sur le disque ?

Si je me souviens bien, l'historique de la session en cours s'enregistre par défaut à la fin de la session. D'ailleurs c'est un peu ennuyeux comme comportement quand on a plusieurs terminaux ouverts en même temps: l'historique n'est pas partagé directement entre eux.

D'une part si tu édites encore des fichiers de conf directement sur les serveurs en 2019 c'est que t'as déjà tout faux et pas ta place dans l'industrie

Merci pour ce chaleureux message, j'avais peur de ne pas savoir où est ma place…

Je peux te rassurer: je ne suis pas administrateur système en industrie :-)

d'autre part tu n'as pas besoin d'utiliser l'éditeur présent sur le serveur pour y éditer un fichier (hello points de montages ssh)

Ok, c'est quand même un échec pour un fichier de configuration : pour pouvoir bien l'éditer, tu dois sortir une autre machine.

pour finir avoir de la coloration syntaxique et du linting n'est qu'à un jet de pierre pip/gem/yum/dnf/gem.

Le problème pour un utilisateur normal, c'est qu'il va casser sa configuration puis se rendre compte après qu'il a besoin d'un linter.

Pour du code, ça ne me pose pas de problème, mais pour un simple ajustement de configuration, c'est hyper lourd.

Je pense que la grande différence est le contexte: quand je travaille sur un code python, j'utilise généralement un IDE, car je sais qu'il y a beaucoup de conventions à respecter. J'espère que tout le monde se rend compte que modifier un code, n'est pas du tout un acte anodin et qu'il y a beaucoup de règles à respecter.

Les tabulations / espaces, c'est un des premiers trucs que l'on apprend en lisant des tutos sur python.

Par contre, quand je modifie un fichier de configuration, ça doit être un acte anodin. Il doit être possible de le faire sans IDE (emacs, vim ne sont pas toujours installés sur tous les postes/serveurs).

Un exemple typique, est que je vois un comportement par défaut que je veux changer. J'ouvre le fichier de configuration, je voit que c'est du texte et je l'adaptes selon le reste du fichier. Je le fais avec un simple éditeur de texte (qui ouvrirait un fichier de config avec un IDE ?) et je ne vois pas la différence entre espace/tabulation. Maintenant, avec un fichier .ini tout se passe sans problèmes, avec un fichier .yml, il y a 9 chances sur 10 que je vienne de casser mon service/programme.

Je pense que le contexte fait vraiment la différence pour l'édition: pour un code, les gens savent qu'il faut suivre une formation, mais pour une configuration, des administrateurs systèmes, des utilisateurs doivent pouvoir les modifier.

Maintenant, dans le cas de reqman, je comprends l'utilisation de yaml: c'est un outil destiné à des développeurs / testeurs, ça ne me choque pas :)

L'article est très intéressant : le développeur semble conquis par Rust et il présente quelques qualités du langage.

En fait, il ne soulève quasiment pas de points négatifs ! Le point négatif le plus important est l'intégration de Cargo (le système de build/test/…) dans d'autres système de build.

Merci beaucoup pour ce retour, c'est intéressant.

Mon objectif était d'apprendre le C++-17 avec la création de ce nouveau projet. Comme j'avais déjà pas mal jouer avec Glib/Gtk récemment, je voulais l'utiliser pour la Gui simplement.

Si j'ai bien compris, un des grands intérêts d'utiliser Gtk 3, c'est que cette version implémente Gobject Introspection. Cet outil devrait permettre de ne plus avoir besoin de faire manuellement les binding dans le langage cible (comme tu expliquais que c'était le cas pour le C++ gtkmm, glibmm…).

En fait, ça définit la syntaxe d'un fichier .gir qui expose l'interface de manière abstraite du langage d'implémentation (C en l'occurrence pour Gtk). Ce fichier est généré directement par le projet source (donc Gtk).

En lisant ce fichier avec un programme (cppgir pour le C++), il serait possible de générer de manière automatique les interfaces dans le langage cible (ici, C++).

Donc, en théorie, cppgir devait résoudre mon problème, mais je n'ai pas réussi à l'utiliser :-) Peut-être qu'on ne peut pas faire de C++-17 avec, je ne sais pas.

De rien :)

Pour LinuxFr, c'est agréable d'être entouré d'une bonne équipe: Mathieu trouve de bonnes idées d'améliorations et de test et Bruno réagit vite aux demandes de fusion et donne de bons conseils.

Ça prend un peu de temps à écrire les comptes rendus, mais c'est assez chouette pour moi aussi de voir ce qui s'est passé.

Ah ben voilà, je me disais bien que c'était inhumain d'utiliser Emacs avec 2 mains ! Ils devraient ajouter dans leur documentation que pour pouvoir l'employer correctement, il faut utiliser ses pieds :)

A ce sujet, on avait eu un journal très intéressant l'année dernière :-)

Pour les titres, oui, je me suis souvenu, c'est ce que je suis en train d'ajouter avec l'image d'illustration.

Il y avait déjà eu pas mal de boulot à faire pour le panneau latéral et les barre d'outils, alors j'avais laissé ça de côté, mea culpa.

Ahahah, vu la discussion, je crois que j'avais compris tout de travers :)

Quand tu as dit:

J'en profite pour t'informer que de moins en moins de dépêches utilisent la deuxième partie (c'est très casse-pied en modération).

Est-ce que ce qui est pénible, c'est que les rédacteurs n'utilisent plus la deuxième partie ?

Moi, j'avais compris ce matin quelque chose du genre "L'équipe de modération trouve la deuxième partie très casse-pied"… Autant te dire que j'étais un peu surpris :-)

Si je me suis bien trompé, tout va bien, car, justement, la suite des évolutions de l'espace de rédaction va être de mieux agencer tout ça avec l'image d'illustration qui permettra de bien séparé les notions de "chapeau", "illustration" et "contenu" (je dois justement mettre plusieurs titres dans ce contenu).

J'en profite pour t'informer que de moins en moins de dépêches utilisent la deuxième partie (c'est très casse-pied en modération).

Mmhh, c'est embêtant ça, parce que le nouveau design a une autre vision: l'idée c'est que la première partie soit un texte d'accroche très court (genre, 1-2 phrases) qui sera associée à une image d'illustration.

Ceci permet de supprimer ces ciseaux pour la rédaction collaborative pour rendre plus simple l'interface et aussi de faire des jolies vignettes dans la liste des dépêches.

L'idée que mjourdan avait donné:

Un essai d'implémentation pour une dépêche en cours d'édition: