Christie Poutrelle a écrit 236 commentaires

  • [^] # Re: Tropes ?

    Posté par (page perso) . En réponse au journal Critique positive de Terminator Dark Fate. Évalué à 5 (+4/-0).

    Tu te trompes. La tropézienne c'est un gâteau au beurre, sucre et crème patissière: https://cuisine.journaldesfemmes.fr/recette/307482-tropezienne

  • # Je paye mes journaux

    Posté par (page perso) . En réponse au journal Payez vos journaux. Évalué à 10 (+12/-1). Dernière modification le 24/10/19 à 18:49.

    Perso, je paye les journaux que je consule le plus, à ce jour j'ai (au moins, je crois que j'en ai plus faudrait que je vérifie) quatre abonnements:

    • nextinpact,
    • mediapart,
    • arrêt sur images,
    • alternatives économiques.

    Ça fait longtemps que j'ai pas fait le point, mais j'ai comme but de me constituer un budget mensuel adapté à ce que je gagne et ce que je ne dépense pas pour financer la presse, et ce même pour des journaux que je ne lis pas régulièrement.

    D'ailleurs, j'utilise "la presse libre" pour trois de ces quatre abonnements: https://beta.lapresselibre.fr/ c'est dommage que leur offre soit un peu faiblarde, mais c'est vachement bien.

  • [^] # Re: Eclipse

    Posté par (page perso) . En réponse au journal Atom / VSCode. Évalué à 1.

    depuis quand il est nécessaire d'être objectif et exact pour troller ?

    Ah ! Tu avoues !

  • [^] # Re: Eclipse

    Posté par (page perso) . En réponse au journal Atom / VSCode. Évalué à 1.

    Ça fait bien longtemps (ça se compte en année) qu'Eclipse ne m'a pas lâché dans les mains. Et généralement, ça m'arrive que quand j'utilise des plugins en nightly (oui, je suis un grand malade, mais ceux que j'utilise en nightly sont incroyablement stables).

  • [^] # Re: Eclipse

    Posté par (page perso) . En réponse au journal Atom / VSCode. Évalué à 1.

    Oui oui je suis tout à fait d'accord :)

  • [^] # Re: Eclipse

    Posté par (page perso) . En réponse au journal Atom / VSCode. Évalué à 1. Dernière modification le 17/10/19 à 18:41.

    J'ai un peu menti, pour prendre des notes vite fait, j'utilise (mettre ici le préfixe de ton environnement de bureau)-(edit|notepad|…) (le plus souvent gedit pour ma part).

  • [^] # Re: Pour quel langage ?

    Posté par (page perso) . En réponse au journal Atom / VSCode. Évalué à 6.

    Surtout Vim.

  • # Eclipse

    Posté par (page perso) . En réponse au journal Atom / VSCode. Évalué à 3.

    Depuis 2005, ça marche sur Mac, Windows et Linux, et en plus, ça plante moins souvent que VSCode et gère beaucoup mieux les gros projets avec énormément de fichiers.

    Et puis tu mens, VSCode n'est pas écrit en JavaScript, mais en TypeScript.

  • [^] # Re: Bien d'accord !

    Posté par (page perso) . En réponse au journal Snap, Flatpak, Packagekit : c'est quoi ce bordel ?. Évalué à 1.

    Moi, ça me rappelle les horreurs des DLLs dans tous les sens…
    Comme je le disais précédemment, je n'utilise pas snap et pourtant, c'est déjà le foutoir dans le répertoire :

    Encore une fois un commentaire de quelqu'un qui rejette en bloc ce qu'il ne comprend pas, c'est une réaction de réactionnaire.

    La structure des répertoire est entièrement gérée par l'outil (flatpak ou autre) et tient compte d'un très grand nombre de contraintes (partage des fichiers similaires, gestion de quoi appartient à qui, etc…) et ne répond pas à une structure logique écrite par un humain, mais dicté par une réflexion technique et codifiée.

    Ce n'est pas parce que tu ne comprends pas ou n'est pas d'accord avec cette codification que ce n'est pas bien.

    Si ça fonctionne et que tu ne constate pas de bugs, c'est que les gens qui ont écrit les algorithmes qui déterminent cette structure ne se sont pas trompés. Que tu le comprenne ou pas, ça correspond à une logique réfléchie et structurée pour laquelle ce n'est pas ton rôle de s’inquiéter.

  • [^] # Re: pas d'accord !

    Posté par (page perso) . En réponse au journal Snap, Flatpak, Packagekit : c'est quoi ce bordel ?. Évalué à 8. Dernière modification le 16/10/19 à 17:45.

    une catastrophe au niveau sécurité

    Le but est complètement inverse à ce que tu dis, au contraire ça renforce la sécurité. Et comme le dit le commentaire juste en dessous du tiens, tous ces stores permettent de lister et gérer ce qui est installé.

    Ça permet même d'avoir un système de base complètement readonly, ce qui est plutôt un gros plus pour la sécurité des postes de travail.

    Pour moi, c'est un retour arrière comme au temps des tar.gz !

    Les tar.gz tu les décompressais tous au même endroit, avec les shared libraries mélangées, un tar malencontreux qui remplaçait les fichiers d'un autre, etc… Avec des applis containerisées et des dépendances bien gérées, un outil comme flatpak permet justement d'éviter tous les pièges d'antan.

  • [^] # Re: Bien d'accord !

    Posté par (page perso) . En réponse au journal Snap, Flatpak, Packagekit : c'est quoi ce bordel ?. Évalué à 2.

    Je t'ai pertinenté parce que la dernière phrase m'a bien fait rire :)

    Mais plus sérieusement, avoir une gestion de paquets compartimentée, indépendante de la distro, ça a pas mal d'avantages:

    • ça peut permettre aux créateurs de logiciels de se focaliser sur un biais de distribution unique,
    • par la même occasion, à l'utilisateur d'être toujours à jour, et ce même si son OS n'est pas à jour,
    • pour le build des applications, ça permet d'avoir des applis qui utilisent des versions différentes des mêmes bibliothèques partagées,
    • il y a aussi un gros focus sur la sécurité, ça bac-à-sable tout, et c'est pas mal,
    • etc… il y a plein de très bonnes raisons d'avoir ce genre de système de distribution d'application.

    Après c'est pas magique, il y a aussi plein d'inconvénients (beaucoup sont techniques, j'imagine). Mais finalement, pour l'utilisateur final, si une solution émerge et dépasse les autres: avoir un store graphique sympa, et pouvoir installer plein de trucs sans connaître les base de l'utilisation de la ligne de commande d'APT ou autre Yum, et avoir en même temps un semblant de sécurité et l'assurance qu'un logiciel moisi ne va pas pourrir son appareil, c'est plutôt bien.

  • # Flatpak c'est bien

    Posté par (page perso) . En réponse au journal Snap, Flatpak, Packagekit : c'est quoi ce bordel ?. Évalué à 8.

    Bref, c'est le gros bordel

    Ouais, mais c'est bien d'avoir une alternative pour installer un peu arbitrairement des paquets qui ne sont pas dans ta distro.

    Perso j'utilise flatpak pour quelques applis, et c'est franchement pas mal ! Mis à part le cache qu'il faut vider à la main de temps en temps (ça peut monter à quelques gigas assez vite).

  • [^] # Re: Mouais, pas convaincu par l'auteur

    Posté par (page perso) . En réponse au journal je me débarrasse de java. Évalué à 3.

    Juste pour info, je pense qu'avec Java, 99,99% des différences de comportement se situent au niveau des interactions avec l'OS, et ça, quelle que soit ta VM ou ton langage, ces différences existeront toujours, c'est impossible d'avoir une portabilité à 100%.

  • # Je trouve leurs justifications un peu...

    Posté par (page perso) . En réponse au journal un (non-)aperçu du libre . Évalué à 7. Dernière modification le 31/08/19 à 18:34.

    Quand je lis les cites que tu amènes, autant je comprends si le nom peut avoir une consonance injurieuse dans certains langages que des gens veulent le changer, cependant je ne suis pas sûr que ça justifie un fork.

    Mais surtout:

    We all love the GNU Image Manipulation Program, but it only has finite resources and so has to prioritise some changes over others

    Le projet GIMP a pas assez de ressources pour le développement, du coup ils crééent un fork au lieu d'aider les développeurs de GIMP (ouate!) avec très sûrement eux-même moins de moyens que le projet GIMP.

    Là je trouve ça vraiment gros, et relative stupide comme justification.

    EDIT: bon en fait, quand on lit leur page web:

    Glimpse is a fork of the GNU Image Manipulation Program. The goal is to experiment with other design directions and fix longstanding bugs.

    Le but réel clairement affiché est d'avoir de l'attention pour que le projet GIMP avance plus vite sur les points qu'ils pensent être délaissés, et ça, je trouve ça beaucoup mieux comme démarche, tu aurais du citer cette phrase dès le début de ton journal.

  • [^] # Re: Mouais, pas convaincu par l'auteur

    Posté par (page perso) . En réponse au journal je me débarrasse de java. Évalué à 4. Dernière modification le 30/08/19 à 11:13.

    En Java je dois avouer ça fait très longtemps, mais de mémoire:

    • dès que tu utilises un lib native (la lib utilisée par Eclipse pour brancher son UI au toolkit du desktop par exemple, je ne me souviens plus de son nom),

    • dès que tu fais des I/O sur le système de fichier tu pourrais potentiellement avoir des erreurs ou des comportements différents. Par exemple, il se peut que sur certains OS, certaines IOException ne soit juste jamais lancées, et que le développeur ayant développé dessus du coup n'ai jamais traité le cas d'erreur correctement, et puis pouf tu mets en prod, et paf ça pète,

    • des politiques de sécu par défaut sur la JVM ou des droits d'accès de l'OS différent, ça pourrait peut-être ?

    J'hypothèse beaucoup là, mais genre de truc classiques, qui peuvent être nombreux.

  • # Petit détail

    Posté par (page perso) . En réponse au journal CSS LinuxFR. Évalué à 2.

    Je pense que le détail le plus perturbant sur la nouvelle CSS c'est la marge sur les Hn du titre des posts (que ce soit dépêches ou journal) − ils n'auraient pas du laisser le margin-top sur le titre, car le padding du conteneur est déjà là, le résultat c'est que la marge en haut et en bas des carrés ne sont pas la même, c'est à la fois très perturbant, pas très joli, et ça fait beaucoup d'espace vide pour rien.

  • [^] # Re: Mouais, pas convaincu par l'auteur

    Posté par (page perso) . En réponse au journal je me débarrasse de java. Évalué à 3. Dernière modification le 29/08/19 à 18:47.

    Je suis globalement d'accord avec ton commentaire, seulement si les développeurs n'ont pas de VM, je comprends que du coup un jour un mec ai eu la géniale (sarcasme) idée de mettre la prod sur le même OS plutôt que de faire l'inverse et forcer les développeurs avec une VM iso. Je le comprend la finalité, mais par contre clairement le type s'est trompé de méthode.

    Par contre, c'est surtout:

    o_O WTF ça doit être le mot multi-plateforme qui n'est pas compris

    que je dénigre. C'est pas parce que Java permet d'être multi-plateforme que le code que tu fais avec l'est forcément, et l'auteur d'origine ne semble pas comprendre ça lui même.

  • # Mouais, pas convaincu par l'auteur

    Posté par (page perso) . En réponse au journal je me débarrasse de java. Évalué à 3.

    J'ai lu l'article en lien: http://mageiacauldron.tuxfamily.org/Blog20190829JavaBienCestJavaOuLaCata

    Et je tiens à réagir sur un point (autre le fait que le style d'écriture est pas terrible, et que la police de caractère soit minuscule et donc illisible par défaut, ce qui aide encore moins):

    les développeurs sont sous windows, donc on déploie en prod' sous windows o_O WTF ça doit être le mot multi-plateforme qui n'est pas compris (outre un souci de compétence de part et d'autre, vu que je l'ai entendu d'une entité ayant technical services dans son intitulé : j'ai quelques doutes sur les deux mots depuis…)

    Je suis extrêmement surpris de la part de quelqu'un qui se défini comme un "architecte d'entreprise et le plus souvent architecte technique" d'être outré par le fait que les environnements de développement et ceux de la production doivent être forcément les mêmes dans une entreprise. Autant je suis d'accord sur le fait que le choix de Windows sur la production conditionné par les machines des développeur soit terriblement stupide, je reste néanmoins convaincu qu'il est primordial que les développeurs travaillent sur un environnement s'il n'est pas complètement iso à minima se rapproche de la production, surtout dans le contexte d'applicatif métier. Quant bien même Java assure beaucoup de portabilité, il y a toujours des différences de comportements, surtout si à un moment ou un autre tu dois faire des entrées/sorties vers le système en dessous. Tu élimines un grand nombre de problème en imposants aux développeurs cette contrainte. De plus, aujourd'hui avec les conteneurs et les machines virtuelles, c'est très facile de répliquer un environnement et ce que quel que soit l'OS du développeur (sauf MacOS, parce que c'est terriblement lent) certainement pas en terme de dimensionnement, mais au moins en terme de contraintes et de versions logicielles.

  • [^] # Re: critiques

    Posté par (page perso) . En réponse au journal La spécialité N.S.I. de la réforme du lycée ( épisode 2 ). Évalué à 1.

    Exactement, je suis tout à fait d'accord, il faut toujours partir du besoin et uniquement du besoin de base, et appréhender la complexité dans un second temps quand on est plus à l'aise avec. Pour apprendre, on est obligé d'en passer par là.

  • [^] # Re: critiques

    Posté par (page perso) . En réponse au journal La spécialité N.S.I. de la réforme du lycée ( épisode 2 ). Évalué à 1. Dernière modification le 23/05/19 à 17:09.

    Bah en même temps, la file c'est une structure de base utilisée partout, et pour comprendre les structures plus compliqués basées sur le pattern, faut déjà comprendre le besoin de base. Par exemple quasiment tous les systèmes événementiels sont basés sur des files d'évènements, et ce même si l'implémentation peut parfois être beaucoup plus complexe, souvent pour des raisons de concurrence d'accès et de performance principalement, le fait est que ce n'est rien d'autre qu'une simple file d'un point de vue besoin et algorithmique.

  • [^] # Re: critiques

    Posté par (page perso) . En réponse au journal La spécialité N.S.I. de la réforme du lycée ( épisode 2 ). Évalué à 2.

    Et clairement le tableau de PHP n'est ni FIFO ni FILO

    En effet, mais tu peux l'utiliser comme tel d'un point de vue algo, avec les fonctions array_pop() array_push() et array_shift() et autres joyeusetés.

    À mon avis, quand un programme parle de FIFO et de FILO, c'est qu'on parle de structure de données où on n'a pas le choix.

    Bien ça dépend, je pense que l'enseigner comme des patterns, c'est pas une mauvaise idée, c'est un comportement dont on a souvent besoin. Après on l'implémente jamais de façon académique, on est d'accord.

  • [^] # Re: critiques

    Posté par (page perso) . En réponse au journal La spécialité N.S.I. de la réforme du lycée ( épisode 2 ). Évalué à 2.

    J'imagine que ça varie de language à language (si on parle des lib standard) ou de lib en lib. Après les implémentations de file et pile y'en pléthore et on en utilise souvent sans s'en soucier. Des fois on utilise des choses qui ne sont ni des piles, ni des files, mais les deux à la fois, mais on les utilise en file ou en pile. Typiquement en PHP l'array est à la fois un sorted set, une liste, une pile, une file, un vecteur et une hashmap, mais selon le besoin on l'utilise en file, en pile, en liste, en set ou en hashmap.

  • [^] # Re: critiques

    Posté par (page perso) . En réponse au journal La spécialité N.S.I. de la réforme du lycée ( épisode 2 ). Évalué à 2.

    Sérieux ? Parler 2 fois de file et piles ? Utilisez-vous ce genre de structure ? Pour ma part, cela a dû m'arriver une ou 2 fois, en 20 ans. Les hash et les dico, c'est l'inverse.

    Je suis sûr que t'as déjà utilisé des "stack" et des "queues", et finalement, c'est pas si loin que ça ! Y'a toujours une fois par semaine un moment où t'as besoin d'une "pile" et d'une "file" c'est juste que tu utilises une implémentation plus moderne avec un nom différent et t'as oublié que "file" et "pile" c'est juste des patterns, pas des structures de données en tant que telles.

  • [^] # Re: Premier vote

    Posté par (page perso) . En réponse au journal Appel de plusieurs organisations à imposer un minimum d'interopérabilité pour les GAFA. Évalué à 10.

    Je n'ai pas moinsé, mais j'ai arrêté de lire au deuxième emploi de l'écriture inclusive. Par contre j'ai suivi les liens pour aller voir de quoi il parle.

  • [^] # Re: Pourquoi 2 ports M.2

    Posté par (page perso) . En réponse au journal Sélection d'un PC libre. Évalué à 2.

    Ah oui, c'est violent sur un laptop les trois disques.