Julien Jorge a écrit 590 commentaires

Je chiffre le disque au cas où je me ferais cambrioler. À moins que le voleur ne l'embarque en le maintenant allumé, trouve le mot de passe de la session ou un autre moyen de se loguer, il ne devrait pas pouvoir récupérer mes trucs.

En terme de source d'emmerde ça n'est pas énorme non plus. À côté de ça, en dix ans j'ai eu un ordi volé (de boulot, pas chiffré), et un ordi jeté, pas chiffré non plus. Pour ces deux là je ne saurais dire si ce qu'ils stockaient a disparu ou si ça a été copié et conservé, et ça me perturbe un peu. Il n'y avait plus grand chose de personnel dessus mais je préfère être prudent pour les prochains.

Cette popup m'agace aussi pour quasiment les mêmes raisons : quand je veux éteindre, c'est pour éteindre, souvent parce que je pars faire autre chose. Et j'ai aussi un disque chiffré qui m'oblige donc à attendre la demande de mot de passe au redémarrage, donc c'est hyper frustrant.

Si le but est de faire l'installation à froid, pourquoi ne pas la programmer pour le prochain démarrage plutôt que d'imposer un redémarrage sur le moment ?

Je te rejoins complètement, et ce n'est pas le seul truc qui me chiffonne dans cet article.

D’expérience, je pense qu’il faut remplacer la revue de code par la revue de conception.

C’est-à-dire demander d’abord aux développeurs de définir comment ils vont résoudre un problème en écrivant le plan de leur solution technique. Et ensuite de relire et de commenter cette conception.

Ça c'est n'importe quoi aussi. J'ai vu un paquet de fois des belles planifs sur tableau blanc tomber à l'eau dès la première ligne de code. Croire qu'on peut résoudre toutes les questions d'implémentation sans coder, et que si ça ne marche pas c'est qu'il fallait réfléchir mieux, c'est se fourvoyer. C'est même la raison pour laquelle on ne fait plus de cycle en V.

Pour moi la question de la conception doit se faire « en gros », et le moment du chiffrage est un bon moment pour échanger là dessus : on communique sur les approches et on élimine les plus gros problèmes.

Les daily/le stand-up sert à remonter les soucis qu'on rencontre sur le terrain : on communique sur les problèmes, on les élimine ou on les contourne.

La revue sert à partager l'information et affiner des détails : on communique sur comment les choses sont faites en pratique. C'est autant au bénéfice du relecteur que du codeur.

Dans toutes les boîtes où je suis passé ces trois étapes étaient la raison pour laquelle les projets étaient fluides. Trois points de synchro pour communiquer et le reste du temps on est bien tranquille. Les seuls soucis que j'ai eu étaient des galères d'humains de mauvaise volonté qui se pointaient au stand-up en râlant à propos du commercial (c'est pas le sujet) ou du patron (toujours pas le sujet), ou encore des gens qui ne voulaient pas retoucher à leur code crado en revue parce que « boaf, ça marche comme ça », voire des héros fiers bloqués en refusant d'échanger à propos de leurs galères. Au final ça me semble simple : si tu joues en équipe, ça marche bien, sinon c'est la merde.

C'est cool les rouleaux, combinés avec la tendance « on a des écrans horizontaux/larges, ça n'a pas de sens de restreindre la longueur des lignes », il y a moyen de se retrouver avec des rouleaux rédigés « en paysage ».

Cinq mètres de texte avant de revenir à la ligne, parce qu'on est au 21è siècle bon sang :D

Ceci n'est pas un message de la modération

Bonjour papap,

On dirait que tu subis une belle série de journaux négatifs depuis quelque temps. J'en suis navré. Les sujets abordés ne semblent pas trouver pas écho parmi les lecteurs du site.

Je trouve personnellement bien dommage que tu restes dans cette voie. Tes contributions au libre étaient plutôt intéressantes et j'appréciais de lire tes articles sur les jeux vidéo et autres sujets annexes. L'effort de regrouper des jeux sous Linux sur un même support me semblait intéressante, ou du moins constructive, même si le support était discutable.

Le site Linuxfr et très influent dans le milieu du libre et aussi très fréquenté. Ainsi, quand on a un site web cité avec un lien dans un article, cela se voit dans les statistiques qui présentent un pic de fréquentation. Il devient rapidement clair pour les influenceurs qu'il faut cibler ce site. Les administrateurs de Linuxfr, devraient pouvoir le constater : il devrait y avoir dans les 150 pseudos concernés et plusieurs pour la même adresse IP.

As-tu des chiffres pour appuyer ces propos ? De mon humble expérience, la visibilité apportée par une publication ici n'est pas si remarquable que ça. À la grande époque de Plee the Bear et de LinuxFr.org la première annonce n'avait amené que quelques milliers de hits.

Bref, revenons à tes journaux. Insister sur ces sujets ou pointer des hypothétiques défauts du système de notes, de karma, ou autres trucs de ce site, ne t'amèneront rien de positif. Si tu vois des soucis je t'invite à ouvrir une entrée de suivi et à y suggérer une alternative ou un correctif. Si tu veux parler de complots, de manipulations, dans n'importe quel domaine, je t'invite à y réfléchir à deux fois. Si tu veux parler de technique et de sujet libres, alors bienvenue parmi nous :)

Cet argumentaire de « ne pas réinventer la roue » est pour moi un automatisme malvenu que les gens de conseil sortent à tout va pour se donner du crédit. Je pense au contraire que si tu es débutant tu as tout intérêt à réimplémenter des choses existantes ; c'est ce qui te fera passer du stade « connaître » au stade « comprendre ».

À titre d'exemple, j'ai appris à l'école ce qu'étaient des arbres binaires équilibrés mais ce n'est qu'en implémentant un AVL que j'ai compris comment ça fonctionnait. Pourtant mon implémentation n'était qu'une roue mal fichue, mais je l'ai utilisée, j'ai rencontré des problèmes qui m'ont amené à encore plus de réflexion, je l'ai confrontée à des outils plus mûrs pour en apprendre d'avantage.

J'ai aussi codé le chargement d'images bmp, tga, pcx, gif et autres. Cela n'a aucun intérêt dans un projet puisque de nombreuses bibliothèques le font déjà bien et que certains formats sont complètement obsolètes, et en plus je connaissais déjà tous ces formats. Et pourtant ça m'a fait me confronter au RLE, à LZW, à la question de la représentation des couleurs, aux formats palette, rgb16 et autres. À l'époque je confrontais mon code aux temps de chargement d'ACDSee, ce qui m'a amené à la question de l'optimisation. C'était aussi un bon exercice de suivi de specs puisque tous ces formats sont bien définis et que les documents techniques sont disponibles. Il y a en particulier plein de variantes de gif et j'avais dû rassembler de nombreux exemples pour valider l'implémentation.

Réinventer la roue c'est aussi apprendre à gérer un projet. Si tu te dis, par exemple, « je vais implémenter une messagerie instantanée » tu vas devoir poser un cadre. Est-ce que le client tourne dans un terminal, une app desktop, un navigateur ? Comment le serveur fonctionne-t-il ? Gères tu les sockets toi-même, utilises-tu des bibliothèques pour cela ? Est-ce que tout passe par le serveur ? Est-ce du pair à pair ? Comment gères-tu la sérialisation ? T'appuies-tu sur un protocole existant ?

Savoir poser des limites, sélectionner des fonctionnalités et cadrer le projet pour l'amener à terme, c'est aussi quelque chose qui se comprend en pratiquant.

Enfin même de manière professionnelle il m'est arrivé de réimplémenter des choses pour des raisons de coût : nous commencions avec l'outil d'un tiers puis nous le remplacions par quelque chose rendant le même service pour un coût moindre et des performances meilleures.

Moi je crois que les bons sportifs ne sont pas dans les gradins à manger des chips. Je crois que les bons musiciens jouent tous les jours, reprennent des morceaux existants qu'ils jouent du mieux qu'ils peuvent, avec des accords ratés et en passant à côté de subtilités. Ce n'est sans doute pas aussi bien que le morceau original mais ça peut quand même être une belle reprise, et surtout ça les rend meilleurs à ce qu'il font.

Alors si tu es débutant, et d'ailleurs ça marche aussi si tu es expérimenté, et que tu réponds à une offre de la boîte où je travaille, mon conseil est d'avoir :

• un CV court qui va à l'essentiel : « j'ai fait ceci et cela, ici et là bas » ;
• du code public et une explication du pourquoi, ce que ça tu as appris et comment tu t'y prendrais si tu devais le refaire ;
• éventuellement des liens vers des articles plus ou moins techniques que tu as écris (un journal sur LinuxFr.org par exemple :)), que je puisse voir que tu peux faire preuve de réflexion, d'analyse, de critique, ou que tu peux expliquer quelque chose à un tiers. Pas forcément lié à l'informatique : une recette de cuisine, comment tu as perdu 10 kg, comment tu as construit un abri de jardin, ou ton ressenti sur la gestion d'une vieille colonie de vacances ; peu importe du moment que ça ressemble à de l'analyse, de la critique constructive, de la réflexion.

Je vois que dune-dynasty se configure avec CMake, du coup pour commencer cloner le SDK d'Emscripten et lance

./emsdk install latest
./emsdk activate latest

et puis ensuite tu peux essayer cmake . -DCMAKE_C_COMPILER=path/to/emcc -DCMAKE_CXX_COMPILER=path/to/em++ du côté de dune-dynasty.

À partir de là c'est essai/erreur :)

Je tente une reformulation alors :)

Il n'y avait pas besoin d'un nouvel outil pour gérer du Json en C++, il y en avait déjà plein. Mais comme il n'y en avait pas dans Boost ça faisait comme un trou au niveau de ce projet.

As-tu rencontré des soucis dans les limitations d'Emscripten concernant les threads, exceptions ou autres ?

C'est vrai que Boost a pas mal perdu de son panache depuis C++11.

J'ai l'impression que l'arrivée du parseur Json n'intéresse pas grand monde et est là plus pour combler un manque que pour répondre a un besoin. Aujourd'hui le Json en C++ ça se joue plutôt entre nlohmann-json et simdjson.

Dans les trucs que j'aimais bien dans Boost il y avait Boost.Signals2 et Boost.Preprocessor. J'avais joué avec Boost.Spirit aussi et j'espère que je n'aurai jamais à y retoucher. À part ça, quelques algorithmes ici et là.

Et puis quelle galère pour compiler tout ça :(

Lapin compris. Tu aurais un exemple ?

En l'occurrence je pensais à un truc qui ressemble à ce qui suit. Intuitivement j'aurais écris quelque chose comme :

some_list = # …

list_a = []
list_b = []

for s in some_list:
    if s[0] == 'a':
        list_a.append(s)
    elif s[0] == 'b':
        list_b.append(s)

Mais j'ai l'impression qu'on me dirait que ce serait plus Pythonic de faire :

def starts_with_a(s):
    return s[0] == 'a'

def starts_with_b(s):
    return s[0] == 'b'

some_list = # …

list_a = list(filter(starts_with_a, some_list))
list_b = list(filter(starts_with_b, some_list))

Cette notion de "Pythonic", on la retrouve notamment dans des réponses sur StackOverflow. Par exemple :

Using an additional state variable, such as an index variable (which you would normally use in languages such as C or PHP), is considered non-pythonic.

Et là, perso, je me dis qu'utiliser des indices dans les boucles répond au problème de l'itération depuis 1792, et n'importe quel programmeur de n'importe quel langage peut comprendre une telle boucle. Est-ce que ça vaut le coup de l'éviter ? Pour quel gain ?

Je ne connaissait pas Docker Desktop, merci.

Est-ce que la version OSX permet d'avoir un conteneur OSX ? L'idéal pour moi serait de pouvoir lancer par exemple XCode dans un conteneur, ou quelque chose dans le genre.

Ça marche bien par ici d’ailleurs, l’idée étant que tu peux débiter les pires saloperies, la modération ne fera rien tant que ton texte est bien écrit.

La modération aimerait ne pas avoir à être juge, ni se mettre à censurer ceux qui veulent s'exprimer. Les journaux sont explicitement ouverts à tous les sujets dans les limites de ce qui est évidemment illégal.

Personnellement j'aimerais vraiment que ces contenus disparaissent, mais voilà : on a des membres qui viennent colporter des bêtises, et au lieu de laisser le journal mourir à -42 sans commentaires on a une communauté qui vient alimenter la discussion parce qu'IL A TORT C'EST N'IMPORTE QUOI BON SANG ! Et on se retrouve avec un torrent de caca dans les commentaires pendant des semaines.

Alors qu'il y a au moins deux bonnes méthodes pour faire disparaître ce genre de contribution :

• ne pas y répondre pour leur faire passer l'envie de poster ce genre de sujets ici,
• soumettre des journaux pertinents pour amener une bonne ambiance et atténuer le poids de ces contenus sans intérêt.

Je vois que tu arrives à poster sur LinuxFr alors je t'invite à continuer à écrire des journaux, comme tu l'as déjà très bien fait par le passé, et à laisser mourir ce journal sans intérêt.

On peut avoir une idée du volume et de l'offre sélectionnée pour se faire un avis.

Oui, rclone size me dit:

Total objects: 15705
Total size: 82.180 GBytes (88240142824 Bytes)

Ce que confirme le tableau de bord sur AWS.

La facture de décembre est de $1.09. Je ne crois pas avoir sélectionné d'option en dehors d'avoir créé un compte AWS. Ensuite j'ai créé le bucket, je l'ai mis en ue-west et pour la classe de stockage c'est « Unizone – Accès peu fréquent ».

Je fais aussi mes sauvegardes sur aws, avec le même débit. De mon côté ça tourne la nuit.

J'avais regardé les tarifs de glacier et de souvenir il y avait un coût non négligeable lié aux nombre de requêtes. Comme je fais un rclone chaque nuit sur un gros dossier je craignais que le nombre de requêtes soit trop élevé, du coup j'envoie tout sur S3. Ça me coûte environ un dollar par mois.

Par rapport à ton script, que se passe-t-il quand tu reprends la main, la copie est en pause ? Interrompue ? Chiffres-tu tes données avant de les envoyer ?

Merci pour cette excellente dépêche, merci en particulier à Jehan car c'est toujours un plaisir d'avoir des nouvelles aussi détaillées de GIMP.

À titre personnel j'apprécie en particulier le côté « juste libre » de ce que vous faite avec LILA. On parle régulièrement ici de licences NC et ND, et que « oui c'est de l'art c'est pas pareil que du code ». De votre côté vous faite de l'art et du code, tout est en BY-SA, c'est juste simple. Bravo à vous.

Une petite question technique pour finir : maintenant que la migration vers GTK 3 est terminée, entamez vous la migration vers GTK 4 qui vient de sortir ?

J'aime bien l'idée mais j'y vois pas mal d'inconvénients :)

• Je plussois sur l'intérêt de documenter le site d'appel, mais en l'état on n'a plus les noms ni les types des paramètres dans la signature de l'appelé.
• Second problème, l'appelé est forcément template. Ais-je envie d'augmenter mes temps de compilation pour pouvoir nommer les paramètres côté appelant ? Probablement non.
• Comment passer des paramètres par adresse ? Combien de copies des paramètres sont faites entre l'appelant et l'appelé ? Sur cet exemple j'ai déjà une copie superflue :

#include "../include/params14.hpp"

#include <cstdio>

using namespace params14::literals;

int copy_count = 0;
int assign_count = 0;

struct copy_counter
{
  int value;

  copy_counter(int v) : value(v) {}
  copy_counter(const copy_counter& that)
    : value(that.value)
  {
    ++copy_count;
  }

  copy_counter& operator=(const copy_counter& that)
  {
    value = that.value;
    ++assign_count;
    return *this;
  }
};

template<typename... KWArgs>
void foo(KWArgs&&... kwargs)
{
  auto args = params14::parse(std::forward<KWArgs>(kwargs)...);
  printf("value=%d\n", args.get("p"_kw).value);
}

void bar(const copy_counter& p)
{
  printf("value=%d\n", p.value);
}

int main(int argc, char** argv)
{
  copy_counter p(argc);
  foo("p"_kw=p);
  printf("named:\ncopies=%d\nassignments=%d\n", copy_count, assign_count);

  copy_count = 0;
  assign_count = 0;
  bar(p);
  printf(
         "good old syntax:\ncopies=%d\nassignments=%d\n",
         copy_count, assign_count);

  return 0;
}

Perso je trouve la difficulté dans le kn, à savoir si ça se prononce comme dans knife ou Knuth par exemple.

Au final je prononce le K à la française.

[…] ta question était purement théorique pour faire chier le peuple […]
[…] comme un bon facebookien, tu pollues les commentaires pour déverser ta rage extrémisante sans même avoir pris le temps de lire de quoi on parle.

Comme tu y vas !

Ça m'amuse parce qu'en lisant ton journal et en voyant « Creative Commons » sans précision j'ai tiqué aussi. Pas sur le sens des mots, c'est plutôt que j'ai trouvé cela très étonnant de ta part car je ne doute pas que tu connais très bien LinuxFr.org et que tu sais très bien que sans précision ça va dégénérer dans les commentaires.

Du coup je pense que tu as volontairement omis la précision pour générer ces commentaires, auxquels tu peux réagir pour faire encore plus de bruit et asseoir ta présence. Mais bon, peut-être que j'extrapole :D

C'est pas mal comme solution, merci. J'ai mis une IP fixe, pas de passerelle et pas de DNS, maintenant ça imprime bien.

Merci, grâce à cette commande (en root) l'imprimante apparaît bien. Elle est partagée deux fois : une fois par avahi et une fois par cups. Pas de chance, l'impression ne se lance sur aucune… Mais ça me fait déjà un peu avancer !

C'est obligatoire en effet, je préfère que l'imprimante n'ai pas accès à Internet et je n'ai pas envie de gérer des routes pour elle :)

Pour la procédure j'ai suivi cette page. En gros :

1. activer le débogage USB sur le téléphone
2. connecter l'appareil en USB
3. adb reboot bootloader, pour accéder au menu de boot
4. fastboot devices, pour vérifier que l'ordi voit bien l'appareil
5. fastboot oem unlock, pour débloquer le bootloader
6. redémarrer le téléphone s'il ne le fait pas tout seul
7. récupérer un TRWP récent
8. refaire 1 à 4 pour revenir au bootloader si nécessaire
9. fastboot flash recovery trwp*-mako.img
10. fastboot boot trwp*-mako.img
11. rebooter en recovery (i.e. lancer TRWP sur le téléphone)
12. cliquer sur Wipe puis Format data
13. récupérer une image de LineageOS, par exemple https://androidfilehost.com/?fid=8889791610682908446
14. dans TRWP cliquer sur Advanced puis ADB Sideload puis swiper
15. sur l'ordi, adb sideload lineage-15-1-20200807-UNOFFICIAL-mako.zip

Si jamais le téléphone se met à redémarrer en boucle, maintenir le bouton volume bas pour qu'il s'arrête au bootloader au redémmarrage.

C'est pas de leur faute, il faut dire qu'avec la crise qu'on traverse… Heureusement qu'ils étaient là sinon ça aurait été pire.

Je pense l'avoir déjà dis, mais peut-être que le problème de vitesse de compilation de C++, c'est juste que les gens font de la merde, à tout inclure comme des porcs sans réfléchir?

Qu'est-ce qui te fait croire ça ? ;)