Toufou a écrit 1369 commentaires

ah non, c'est bien un doublon avec /tmp qui pour le coup est une des incohérences FHS (avec le /usr/local qui fait doublon avec /opt)

Pour moi ça respecte parfaitement la FHS.

Certes mais

/usr/lib Libraries for the binaries in /usr/bin and /usr/sbin.

On peut en effet considérer la conf par défaut comme une Library / asset, pourquoi pas.

Pour ma part, dans ce cas, je l'aurais casé dans /usr/share mais bon.

Edit :
En relisant le thread je viens aussi de noter le

tout ce qui ne doit pas survivre à un redémarrage dans /run

J'imagine que l'auteur a voulu dire /tmp.

dans le cas de NetworkManager c’est vaguement respecté

C'était totalement sarcastique car au dessus il est dit :

la configuration poussée par un paquet logiciel (donc, par ta distribution) est dans /var/lib ou /usr/lib

J'ai du mal comprendre cette partie. J'ai cru comprendre qu'une partie de la conf était dans /var/lib et dans /usr/lib (ce qui se fait pour systemd par ex).

Donc un non respect de la FHS, sauf a considérer que cette conf est une donnée du programme destinée à varier continuellement (comme les leases dhcp) ou une donnée qui devrait être partageable et en lecture seule (comme les manpages ou les fonts par ex).
Après le respect de la FHS n'est pas un dogme, juste une proposition de bonne pratique d'uniformisation. Ça se discute et chacun fait ce qu'il veut dans son soft / sa distro. C'est juste qu'on repassera pour la soi disant uniformité/simplification des configs : c'est pas vraiment mieux qu'avant ~2005 ou on avait un gros yaourt sh dans /etc : maintenant on l'a dans tout le disque et dans 36 langages / formats et systèmes.

Ça fait vieux con mais c'est factuel. Et puis je suis aigri suite à une mauvaise expérience avec l'usage de shadow services de systemd et leur non support des priorités pour intégrer un script rc sysV : merci RaspiOS.

Note : le fait qu'il y ait aussi de la conf dans le binaire (comportement, option de compil etc, remonté par misc) relève plus du point de vue 'théorie sécurité paranoïaque' car dans ce cas tout le disque dur n'est que config (les données aussi peuvent potentiellement contenir de la conf ou induire un comportement). C'est tout à fait vrai mais bon, j'évite de mettre le pied dedans.

c'est pas moi qui le dit c'est la fhs 'should be read only'

on se demande bien pourquoi il faudrait vaguement respecter la FSH qui dit en gros que la conf est dans /etc, que /var continent les choses qui changent continuellement utilisées par les programmes et que ce qui est dans /usr devrait être read only.

Soyons disruptifs ! Fight the war fuck the norm ! Embrace and extends !

HBL : Horizontal Blank Line => la fin du tracé d'une ligne, la VBL (Vertical Blank Line) c'est la même chose pour l'affichage de la dernière ligne de l'écran. Une interruption est associée par défaut d'ailleurs à chacun de ces évènements.

ST = l'atari ST oui dont le chipset vidéo (shifter) ne supporte pas le scrolling hardware (d'où les techniques de sioux pour y arriver), c'est une des amélioration arrivée avec le STE (ça, la palette étendue, le blitter…)

Désolé, j'aurais du développer :)

L'explication de Léonard est claire, mais j'ignorais que hardscrolling et syncscroll étaient synonymes pour certains et bon, pourquoi pas après tout on joue avec un aspect matériel (le timing avec la hbl).
Bêtement je fais la distinction a cause du STE qui permet le hardscroll sur le simple tripotage d'un registre du shifter alors que sur ST sans syncscroll point de salut :o)

elle existe toujours bel et bien.

pouet.net est la porte d'entrée et permet de se tenir au courant de ce qui sort (et des parties). Il y a de belles choses récentes y compris sur vielles machines :)

Il a été un des premiers à faire du scrolling hardware + fullscreen sur Atari ST (alors que ce n'est pas possible, il n'y a rien dans le hard qui permet de le faire,

Heu comment faire un scroll hardware+fullscreen sur ST si ce n'est pas possible ? :D A coup de fer a souder ?
Tu veux probablement dire : "alors que ce n'est pas fait pour", ce qui correspond plus aux joies de la démo :D Quoique…

Si tu veux maximiser le bonheur de l'humanité, ça n'est pas aux franciliens que tu dois redistribuer la fortune de Musk de toutes manières :-)

non mais c'est pour (me) donner une idée en prenant une zone riche de la planète. Trop de zéros ne veulent tellement plus rien me dire que je me plante d'un facteur 1000 et que je ne m'en aperçois pas.

J'aurais pu dire que d'après le crédit suisse il faut 2000 Musk pour couvrir la richesse mondiale 2022. Je dis Musk mais ce n'est pas le seul, c'est juste le 1er (enfin, plus depuis qu'il se fait amputer de 50M$ de Tesla :o))

Pour le reste, sur ou sous estimer les riches, le pouvoir d'achat, le bonheur, si c'est bien, si c'est mal, etc. c'est une question du point de vue et ça se discute autour d'une bière :)

les deux mais oui c'est pendant 7 mois pas 833 ans :)

car le 1% restant est suffisant pour vivre une vie plus que confortable

La fortune de Musk (250 M$) paye mon salaire à la région parisienne (~12m d'habitants) pendant ….. 833 ans :D Et je suis dans la moitié la mieux payée de France.
On peut comprendre qu'avec 1% de la fortune de Buffet, une famille puisse vivre pépère.

Merde … démasqué
Bon spa vrai je suis devenu débianeux depuis 2003 ou 4 mais je ne renie pas mes origines ;)

Oui j'ai bloqué sur le "je veux bien faire un paquet snap" et pas sur le "à la limite" préfixe… Ça m'apprendra à (bien) lire…

Mais au final je suis convaincu que le tgz c'est l'avenir car si tu fais du très bon boulot libre, ça s’empaquette tout seul sur toutes les plates formes.

Tout le monde n'est pas Firefox ou vim.

Du coup tout le monde n'a pas nécessairement besoin que ton soft soit distribué sur 50 plates formes différentes.

Donc le tgz ça le fait bien ou le bon vieux binaire non ? Plutôt qu'une dépendance à une usine a gaz et à un service à la politique étrange.

Ou alors, je ne distribue pas mon application sur Linux et tu te démerdes. A la limite je veux bien te filer un *.tar.gz qui contient toutes les dépendances que tu va pouvoir extraire dans ton /opt.

Et même qu'on pourrait imaginer des gens (appelons les des mainteneurs) qui s'amuseraient à prendre ça, découper en 200 fichiers ton /etc/monProg.conf (entre autres) et qui en ferait des paquets bien intégrés dans un ensemble qu'on appellerait une distribution.

Ah non c'est trop has been :)

Je trouve que Ubuntu qui cherche à promouvoir snap, ce n'est pas pire que Gnome qui m'a imposé l'installation d'evolution ou KDE qui m'imposerait Kmail alors que j'ai déjà Thunderbird.

ou Windows qui imposerait IE ? :D On a vu le DoJ s’énerver pour moins que ça …
Je sais pas si le DoJ s'attaquerait au libre mais ça péterait : snap vs DoJ

c'est lundi tout est permis :)

le low tech (cafetière italienne)

Tutututu tout ça c'est bien relatif : la cafetière à piston est encore plus moins technique, monsieur !
Ou encore plus plus low tech : la chaussette ou le bon vieux filtre !

le texte donne une définition des « logiciels libres et open source » qui se démarque sensiblement des définitions de la FSF et de l’OSI

Alors j'ai été confronté à ça récemment dans un cadre pro : où on a demandé en réunion si la licence libre des softs d'une boîte "interdisait une exploitation commerciale". Je suis intervenu disant qu'on ne peut être libre avec une clause NC (violation de la liberté 0 FSF) et là c'est parti en live, la personne partant dans du discourt Ballmer (licence virale, clause NC dans du libre, etc.).
Cette personne était pourtant une chargé de valorisation des produits donc en théorie vaguement au courant des licences logicielles puisqu'elle les négocie et s'appuie dessus pour définir ou évaluer des business plans.

Ça m'inquièterait sévèrement que les concepts portés par la FSF et l'OSI (et tout ceux qui tournent autour) soient pervertis consciemment ou non dans les formations de nos collègues juristes ou commerciaux.

Suis-je le seul à rencontrer ça ?

Le dernier pour la route, après j'arrête, c'est en effet totalement inutile ce genre de flamewar. Tu ne comprends pas que je critique ton billet, ta méthode d'argumentation qui porte les biais que tu critiques et non toi en tant qu'humain.

un exemple sur ta méthode vaut mieux qu'un long discours alors je te cite :

Pareil quand tu hasardes des hypothèses sur mon parcours

Donc, dans le paragraphe au titre respectueux de "Des langages qui font n’importe quoi", on a

Si je prends l’exemple de Java que je connais le mieux (vu que je bosse avec depuis près de 15 ans)

suivi de

Des chaines d’héritage qui n’ont aucun sens et qui conduisent à des comportements aberrant (note bas de page n°2).

suivi de

Et là je parle bien du langage lui-même, et pas de l’utilisation qui en est faite.

La note n°2 dit :

Par exemple, l’interface List expose des méthodes de modification, qui sont donc présentes y compris sur les listes non modifiables, qui ont donc des méthodes qui lancent des exceptions quand on les appelle

Ce qui m'amène à te poser la question suivante dans mon post précédent :

implémenter List pour faire un truc immuable ça me semble complètement con (…), tu as un exemple de classe dans la StdLib java qui fait ça ? Avec 15 ans d'XP tu as surement ça sous le coude.

et tu me réponds dans le post précédent :

Oh, à propos de Kotlin, je te conseille de regarder la doc le leur implémentation standard de List : elle est immuable

Bon, soit tu ne comprend pas ma question (peu probable, enfin j'espère), soit tu ne prends pas la peine de te documenter pour me répondre (très gentil, merci), soit tu as dit de la merde dans le billet d'origine, tu t'en es aperçu et ouille ça pique.

Mais tu en rajoutes une couche surréalistement péremptoire :

Et à l'usage tu n'as pas tant besoin que ça des listes modifiables.

Source : "c'est connu Khalessi"

non franchement, tout ton billet est sur le même moule, tu craches ta frustration, ta confusion entre les choses … => /dev/null

Et là tu décales le problème sur une attaque ad hominem, crois moi il n'y en a pas vraiment. Je critique principalement le fait d'avoir produit un contenu de merde parce que tu ne cherches même pas avant publication à vérifier si tu dis de la merde ou non, le principe même du billet d'humeur.
C'est ce qui fait la différence entre une doc et Raymond au PMU : la première bénéficie d'un travail de relecture.

La seule attaque 'personnelle' que j'assume c'est que tu craches sur les autres 'qui font n'importe quoi et ça c'est cool mais que bien sur la réciprocité est agressive…

import java.lang.reflect;

Merci pour ce retour pertinent et constructif (non).

Ok, je vais détailler ça sera peut-être utile et moins frustrant.
Mais bon, Tu fais un billet d'humeur (non constructif) sur la POO, son usage et son enseignement pourris selon toi, je fais un post d'humeur sur ton billet d'humeur pourri selon moi => où est le problème ?

Les deux phrases m'ayant déclenché cette réaction :

voici un billet sur la programmation orientée objet et pourquoi elle est mal utilisée et enseignée.

et

Si le principe d’encapsulation est correctement respecté (ce qui devrait toujours être le cas en théorie mais ne l’est pas en pratique), l’état interne d’un objet est inaccessible de l’extérieur, et ne peut pas être manipulé directement.

plus le rapide survol des titres :

Un enseignement complètement à la rue (…) l’immense majorité des cours de POO n’expliquent pas ce qu’est la POO : ils expliquent une vision défectueuse de la POO (…) Des langages qui font n’importe quoi.

Donc ça balance sévère et paf, d'entrée une confusion entre deux concepts, l'un fondamental en POO (l'encapsulation), l'autre accessoire (le masquage), je trouve que ça part assez bien pour qu'il ne soit pas nécessaire de continuer et faire savoir que ça vaut pas plus qu'une discussion de comptoir avec Raymond au PMU.

Ça c'est pour expliquer la forme succincte de ma critique dont le fond a semble t'il parfaitement été compris : j'ai pas été mauvais sur le coup en termes de com.

Sur le fond :

Dans les faits, quand on parle d’encapsulation dans le cadre de la POO, c’est pratiquement toujours avec masquage,

Le masquage est un autre concept comme la notion de classe ou de propriété.
Et quand on parle de POO on parle pratiquement toujours dans un contexte de langage à classe (C++, Java, C#…. ) : ça rend la classe implicite ou obligatoire quand on parle POO ? Fuck les prototypes ?

Donc ok, c'est proche et ça va souvent ensemble mais ce n'est ni implicite, ni obligatoire il me semble.

parce qu’une information non masquée a toujours un risque d’être utilisée (au moins lue) hors de son contexte d’encapsulation.

Et alors ? En pratique c'est presque impossible de l'empêcher donc bon…

Le masquage c'est comme la notion de classe ou d'encapsulation (bundling, que j'utiliserai comme terme ensuite, pour éviter la confusion) : un concept.

Après tu l'implémentes (outils) comme tu veux :
- mot clef et mécanisme du langage (ex : private)
- convention de nommage et savoir vivre des codeurs
- menace de mort de l'ordinateur (comme certains registres du TI99 ;) )
Tout pareil pour le bundling :
- mot clefs et mécanismes du langage (ex : class)
- convention de nommage / structures particulières
- il y a surement d'autres méthodes que je ne connais pas

Donc soit tu parles du concept (on peut cacher des choses) soit tu parles des outils (on le rend private), soit tu parles des pratiques (c'est bien/c'est mal).

Là tu nous parles de POO et d'encapsulation au sens concept car c'est dans une définition.
Je ne vois pas du tout ce que la morale ou les outils viendraient faire la dedans.

Surtout, la POO n'interdit pas d'aller utiliser les propriétés et autres comportements : elle se base justement la dessus (via les messages).

Ta définition en deux phrases est d'ailleurs incomplète : il manque les messages, mais pour ça il fallait mieux lire entre les lignes WP que tu as résumées, car il y a une proposition clef : "ils savent interagir entre eux".
Et il fallait la comprendre : ce n'est pas leur comportement qui fait qu'ils savent interagir entre eux, c'est le mécanisme de messages qu'ils utilisent, généralement via l'appel de méthode (une implémentation possible).
Donc non ce n'est pas tout, merci Captain pas si Obvious que ça.

C'est peut-être aussi un détail mais c'est souvent là où se cache le diable : le fait que les objets utilisent un mécanisme de communication pour interagir entre eux me semble légèrement plus nécessaire que le masquage dans une approche POO…

une différence forte entre « encapsulation » et « masquage » n’est pas un consensus du tout

Il se peut, ma mémoire étant ce qu'elle est et ma littérature de référence sur le sujet étant perdue dans les limbes, tu as peut-être raison. En tous cas, même WP FR semble te donner raison.

Et je me demande bien alors comment on appelle le bundling en français…. Pas des structures : il n'y a pas de comportement dedans.
Des paquetages ?

J'instancie des paquetages en python et en perl ? Vraiment ?

Pour moi intégrer le masquage dans l'encapsulation n'est ni plus ni moins qu'un abus de langage par anglicisme (eux ont les 3 mots : encapsulation, bundling, information hiding). Dommage qu'il se répande dans la littérature.

n’est pas un consensus du tout

Quitte à jouer sur les mots et les consensus, est-ce qu'on est toujours dans de la POO quand l'instance d'une classe n'a ni toutes les méthodes ni tous les attributs de sa classe ? On encapsule, on a bien un objet issu d'une 'classe' et pourtant y a comme un truc qui pue….
Je relève les copies dans 3 mois, bon courage pour aller chercher un consensus dans la littérature.

tout est bon pour la poubelle parce qu’un détail ne t’a pas plu

Un concept central n'est pas un détail dans un papier dont c'est le sujet. J'aurais lu ça dans Marie Claire, je n'aurais probablement relevé.

Vois le bon côté des choses, j'ai lu un peu le reste pour te répondre et d'ailleurs j'ai deux questions :
- le coup des List qui intègrent des méthodes de modification => implémenter List pour faire un truc immuable ça me semble complètement con (sauf contexte étrange, genre hack moisi pour se sortir d'un mauvais pas en loucedé), tu as un exemple de classe dans la StdLib java qui fait ça ? Avec 15 ans d'XP tu as surement ça sous le coude.
- tu parles de Kotlin comme 'Langage a JVM' : j'ai cru comprendre que Kotlin se compilait / transpilait pour différentes archi (JVM, natif, JS notamment). Tes mesures ne concernent donc que quand on le fait tourner l'exe sous JVM, mais quid pour les autres supports ? Ou j'ai pas bien capté ce qu’était Kotlin ?

Pour le reste, de mon point de vue ton billet d'humeur me fait penser que
- tu n'a pas bien compris certains concepts de base (encapsulation/bundling, masquage, message)
- tu mélanges concepts (POO), bonnes pratiques (LSP, SOLID, traits) et outils de la POO intégrés au langage (la notion de private, les Enums qui sont des classes de Java)
- tu aurais pu parler des friends ou d'héritage en diamant : la aussi y a du lourd dans la série bonnes pratiques :D
- j'ai l'impression que tu galères parce que tu n'as pas bien compris, gênant après 15 ans de Java… Mais bon JBoss-like, Spring, Hibernate et autres machineries du type ne sont pas Java …. Si ça fait 15 ans que tu fais du légo avec ça, ça peut se comprendre et je compatis pour la frustration…
- tu repompes joyeux les phrases vides de sens de WP (ou sa source), exemple : le laïus sur la conception qui est primordiale en POO => parce que la conception c'est secondaire dans les autres paradigmes ?
- tu balances des dogmes (LSP, SOLID) qui ont les mêmes problèmes que ceux que tu critiques dans l'enseignement de la POO => ils sont aussi potentiellement des freins à la qualité et à la robustesse (notions bien subjectives) de ton code.
- après 15 ans de métier, je trouve étonnant que tu parles de code sans parler de contexte, pourtant le contexte, quand il change, c'est ce qui fait que tu vas tout péter, bonnes pratiques ou non, POO ou spaghetti style. C'est surtout ce qui fait qu'un choix est pourri sur papier, mais qu'en fait c'est pas si con IRL. Qu'il est malin aujourd'hui et complètement débile demain.

Donc, après avoir lu vaguement, ça confirme ma première évaluation : un truc où en quelques lignes je détecte déjà des problèmes sur le cœur du sujet alors que je ne suis pas un cador du domaine => /dev/null. Le reste ne vaudra très probablement pas mieux. C'est pour ça que d'habitude je ne lis pas les billets d'humeurs : les avis de Raymond sur les ZFE et le changement climatique ne valent pas mieux que les miens. J'ai déjà une analyse moisie du monde : la mienne. Pourquoi aller en chercher ailleurs ? Là je me suis fait avoir dans un moment de faiblesse :D
Mais bon, ça m'a permis de réviser mes classiques en m'amusant, en cela, ça n'a pas été totalement inutile donc merci.

Allez pour décrisper, j'avais lu un truc qui m'avait fait marrer (sans doute ici) : le code c'est comme le pet, on ne supporte que le sien :D

Bah ça les dérange pas pour le main facultatif hein…

M'enfin, les goûts et les couleurs toussa….

Je vous renvoie à ce billet pour plus de détails quant à ce que ça implique,

Cool !

Si le principe d’encapsulation est correctement respecté (ce qui devrait toujours être le cas en théorie mais ne l’est pas en pratique), l’état interne d’un objet est inaccessible de l’extérieur, et ne peut pas être manipulé directement.

Ah beh non, pas cool : le mec d'entrée confond encapsulation et masquage…. => /dev/null

Je dois avoir l'esprit tordu (bon, ok c'est une certitude) mais je trouve que ce passage va être nominé dans catégorie 'le détail mis en avant qui ne sert à rien'…
Les parenthèses sont souvent obligatoires car séparant la condition du code à exécuter. Dans le cas de V, ça semble être l'accolade délimitant le code qui est obligatoire, rendant inutiles les parenthèses pour la condition.

Parce que je ne vois pas trop la différence entre

if (condition) do_toto();

et

if condition { do_toto() };

Du coup, à par satisfaire les accoladophiles parenthèsophobes, je ne vois pas trop la killer feature ….

Encore moins rassurant, les vieux sont pareils et en plus ils te disent qu'il faut vivre avec son temps : c'est fini l'informatique à grand papa à coup de shell et de perl.