Christie Poutrelle a écrit 381 commentaires

Ç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).

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

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).

Surtout Vim.

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.

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.

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.

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.

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).

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%.

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.

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.

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.

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.

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.

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à.

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.

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.

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.

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.

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.

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

Présence d'un port SATA et deux M.2 (un seul serait inutile dans l'idéal il en faudrait deux, à défaut un ou zéro c'est pareil).

Question con, mais pourquoi tu veux absolument 2 ports M.2 ? C'est une vraie question, je n'ai absolument aucune idée pourquoi tu statues qu'en avoir qu'un c'est inutile.

Les PC de marque LDLC et les Clevo de PCW c'est les mêmes de mémoire. Il y a quelques années en tout cas c'était le même matos rebrandé, même les noms des modèles de portables étaient les mêmes entre les deux marques.

J'ai eu un Clevo pendant 4 ans, globalement la machine était très bien et bon rapport qualité prix, par contre côté qualité, je suis pas trop sûr, la machine s'est quand même mise à cracher des éclairs jaunes et bleus, l'alim sur la carte mère a grillé, et je me prenais des décharges électriques en la touchant parfois (sur sa fin de vie, dans sa troisième année) − mon avis est sûrement pas objectif en ayant eu qu'un modèle, mais ça m'a refroidi.

Et oui, ça parait étonnant, je n'ai rien d'inutile sur mon bureau, mis à part une feuille qui est originellement posée sur le bureau d'à côté mais dépasse un peu sur le mien. C'est plutôt vide et épuré.