freem a écrit 5059 commentaires

Non… list (verbe seul) n'est pas si lisible quand on n'est plus dans le contexte (on peu lister plein de choses en dehors de la navigation dans l'arborescence) ; et je trouve bien d'avoir la composition verbe-objet :)

Dans un interpréteur de commandes tu as toujours le contexte… et dans du code le contexte devrais être clair aussi, sinon ça pue.
Peut-on vraiment considérer que, quand je fais ls /sys je liste le contenu d'un dossier?
C'est discutable, parce que /sys n'est pas un (vrai) dossier, c'est un dossier qui expose une partie des commandes que le noyau voit.

Je trouve la composition verbe-objet particulièrement imbitable perso, un exemple typique qui m'agace: void FooBar::SetVariable( int source ); int FooBar::GetVariable( void );. Bon, ben, en fait, si ça s'appelait void FooBar::Variable( int source ); int FooBar::GetVariable( void ); ça serait plus lisible à l'usage, moins souvent besoin de scroller ou de lire une ligne coupée.
Toutes les informations sont dans la signature, dans les deux cas. Et quand c'set utilisé, c'set tout aussi simple.
Après pour des langages typés dynamiquement ou qui passent des références volatile par défaut, je dis pas, c'est peut-etre utile les noms à rallonge, vu que le compilateur ne peux rien vérifier…
Comme j'ai toujours dit: je ne suis pas assez intelligent pour me passer de compilateur ou d'analyseur statique, donc le C et le C++ sont plus adaptés à mes capacités intellectuelles limitées que python, perl ou bourne shell :)

Mais je crois que ce que je déteste le plus, ce sont les namespaces imbriqués avec des noms à rallonge, je me souviens vaguement d'une des API de boost qui utilisais 3 couches de namespaces bien longs.
Au final ce que tout le monde fait (tout le monde, y compris les exemples de la doc!), c'est renommer cette pile de merde (pas d'autre mot) de sorte de pouvoir utiliser un namespace beaucoup plus court (sinon il n'y a qu'un appel de fonction par ligne faut dire!).
Je crois que c'était le module filesystem, ou peut-être programoptions? Bref (de toute façon: boost, c'est seulement si j'ai pas le choix).
C'est d'ailleurs le truc qui a fait que j'ai pris Java en grippe quand j'étais gamin^W jeune, les namespace à rallonge. A l'époque si on m'avais dit en 1er que oui c'est long mais on peut les rallonger, j'aurai juste trouvé java débile, et non pas imbitable.

et c'est un équilibre à trouver, toujours.

Il fallait lire "et le reste, c'est un équilibre à trouver, toujours"

Y a t'il une qualité par défaut qu'un logiciel doit avoir ?

Oui.

Et si oui le quel est-ce ?

Avoir le moins de bugs possible.

Le reste, la lisibilité du code, la vitesse, c'est accessoire. La priorité, c'est que le logiciel fasse sans erreurs ce qu'il a été conçu pour faire, et c'est un équilibre à trouver, toujours.
Les diverses optimisations de performance:

• réseau
• mémoire vive
• stockage
• temps CPU

ainsi le coût de maintenance, ce sont des points importants, certes, mais si le programme maintenable; super rapide, mais qu'il ne fait pas ce qu'il devrais, je pense que l'utilisateur va juste le mettre très vite à la poubelle.

Nope, ls -Sl ne fait pas ce que j'ai décrit: ça trie, ok, mais ça affiche toujours tout un tas de bordel peu utile voire gênant: je n'ai pas vraiment envie de révéler (même si tout le monde s'en fout) les username ou les groupes quand je discute d'un problème lié à mes fichiers sur irc. C'est la l'un des gros problèmes de ls pour moi, et j'aurai aimé que cette commande dispose du -o de ps, qui permets de controller quelles colonnes sont affichées.

Dans le cas de ls, pour avoir ce dont je parle, il faudrait un truc du style:

ls -Sl | awk '{print $3, $9}' et ça va casser au moindre coup de vent, parce que la sortie de ls n'est pas soumise à standard…

La bonne façon de faire (portable, standard) serait un truc du genre:

for file in *
do
stat -c "%s\t%n\n"
done | sort -n

Sauf que ça marche pas: stat ne connait pas \t, et en plus ça affiche des tailles en octets, on perds donc la lisibilité du -h.

Je trouve personnellement que le manque de cohérence dans les commande UNIX est pesant, pour rester poli.

Le coût des appels de fonctions et des tables virtuelles ne peut qu'être totalement négligeable pour de tels logiciels

Pourquoi? Qu'est-ce qui empêcherait ce coût d'être élevé en cas d'abus d'héritage (allez, disons qu'il y a 10 niveaux d'héritages, 5 fonctions virtuelles à chaque fois, et que chaque couche a plus de classes que sa couche parente…), de fonctions virtuelles, de dynamic_cast?

Je suis d'accord que le polymorphisme n'est pas à jeter, loin de la, mais de la a dire que ça ne peut avoir qu'un coût négligeable en toute situation, il y a un pas que je ne franchirai pas.

Ca me rappelle le problème des libs qui exportent trop de symboles: ça rend l'OS lent à faire la résolution de nom, augmentant drastiquement le temps de démarrage des applications. Il y avait un article d'un type de RedHat sur ce sujet, je dois avoir ça chez moi dans mes favoris, je vais essayer de le retrouver ce week-end… enfin, si je n'oublie pas d'ici la :D

Ta remarque me fait penser à quelque chose : Comment modéliser ce type de choses en UML ?

Très simple: on ne fait pas. Enfin, je suppose qu'on peut faire un workaround en créant une "classe" qui n'a pas de nom. C'est moche, mais bon, UML est quand même super dogmatique, donc ça force a faire des trucs moches (comme en java ou il faut créer une classe avec une méthode statique pour le main(), parce que sinon spas de l'objet pur… heureusement que le rididule ne tue pas!)

Je pense que pour des langages non objet, UML est assez peu utile en effet. En tout cas, moi ce que j'utilise le plus dans UML, ce sont les diagrammes de classe, qui n'ont évidemment aucun intérêt dans ce type de situation. Par contre je suppose que tu dois pouvoir utiliser d'autres diagrammes (diagramme d'état-transition peut-être?) pour ce genre de choses: je suppose que ça peut servir de hack potable… mais bon, franchement, je n'en vois pas plus que ça l'intérêt.

C'est d'ailleurs valable pour UML de manière générale, je vois ça comme un truc pour faire des jolis dessins pour le chef, histoire qu'il ait l'impression de comprendre ce qu'il se passe.
Comme je l'ai dis, je n'utilise que les diagramme de classe pour ma part, et encore (sauf pour amuser la galerie, dans ces cas la je trouve le diagramme de cas d'utilisation utile, ça remplit les slides…), je ne fait jamais de diagramme complet, ça ne me sers qu'a avoir une vue de haut niveau, pratique pour prendre du recul, réfléchir à l'architecture, ce genre de trucs, mais ça finis souvent désynchronisé de toute façon, et comme on ne peux pas y mettre les fonctions, ben, je m'emmerde pas avec ça.

Après, je ne suis pas non plus un expert UML… je préfère passer mon temps à coder voire écrire de la doc, je trouve ça plus utile (et c'est dans la doc qu'UML à un petit intérêt, mais juste petit).

D'autant plus que certains le font, d'implémenter des OS en rust. Du coup je serais curieux de voir les réactions des devs de redox a ce sujet (j'imagine qu'il n'en ont pas, de toute façon il ne serait probablement pas pertinent de changer le projet pour "si peu").

C'est intéressant pour un débutant en C++: ça ne fait pas de mal de rappeler aux gens qu'utiliser un langage rapide ne sert a rien si on ne sait pas s'en servir, et clairement faire des calculs redondants ou des copies inutiles, ça a un coût potentiellement important sur les performances.

Créer des programmes efficaces reste une activité qui nécessite de réfléchir et de connaître un minimum ses outils, assez pour les utiliser correctement, et surtout utiliser ceux adaptés à la situation.

Je suppose que l'une des prochaines optimisations sera d'utiliser stringview pour éviter les copies?

Je pense la même du tiens (qu'il est débile), parce qu'il ne prouve absolument pas que brl-cad est libre ou ne l'est pas. La seule chose qu'il prouve, c'set que tu ne sais pas, et que tu as la flemme d'aller vérifier. Ce qui n'est pas un problème, en soit, mais ça s'arrête la.

d'autre part je trouve les scripts plus lisibles

Mon avis sur ce point diffère énormément.
Pour moi, la concision, quand elle n'est pas poussé à l'extreme, aide la lisibilité. ls ce n'est pas lisible, list serait bien mieux, mais ListFilesInThisDirectory qui est plus complet est clairement moins lisible que ls pour moi.

Sur certains points, je trouve même powershell plus intéressant que le shell, notamment grâce aux objets. Typiquement, en shell standard afficher la lists des fichiers dans un dossier et leur poids, sans autre information, et trié en fonction du poids, c'est un truc qui me semble incongrument difficile, surtout si on veut un truc stable dans le temps: on ne peux pas utiliser ls, déjà, donc il faut boucler et utiliser stat, puis trier le résultat de la bouche. C'est moche. Il y a peut-être moyen de faire avec find, aussi, mais dans le genre commande horrible à utiliser find se pose superbement, à tel point que souvent j'ai la flemme de -prune et préfère un grep -v pour exclure des résultats…
En powershell ce genre d'opérations est nettement plus simple.

Je ne sais pas pour la conso mémoire, mais par contre je suis d'accord avec toi pour les noms à rallonge.

tu mets quoi dans /home ?

Ca dépends. Déjà, pas les fichiers multimédia, sauf le pr0n, parce que bon, un home sans pr0n c'est un coup à prendre du poids :D
Plus sérieusement je mets mes fichiers de conf, les jeux que j'installe à la sauvage, wine, aussi, qui pèse son poids. Il y a le bordel habituel dans ~/Downloads et ~/Téléchargement aussi, des artefacts de compilation, les mods, cartes et sauvegardes de certains jeux (wesnoth et unvanquished, surtout)…

bin ça induit des SSD de 256 Gio plutôt que 128 Gio : 20 € vs 10 € à l'unité

Bah, je ne connais pas les prix, mais la partition C de ce PC (du boulot) semble peser 212 gigs (flemme de me log en admin pour le diskmgmt.msc). Je ne connais pas la raison derrière ce choix, mais je sais que régulièrement ça fait perdre pas mal de temps aux utilisateurs (non, one drive n'est pas la panacée).

Un OS + utilitaires système peut tenir dans 5 Gio (déjà c'est trop àmha, suffit de regarder côté Alpine Linux ou simplement Debian), 10 Gio c'est pour les mises à jour : plus, c'est pour les jeux1 et leurs données ou les applications (LibreOffice c'est du système ou une application ?

Le problème c'est que trop serré c'est chiant à maintenir :D mais concrètement sur mon PC portable perso (selon df -h):

• /: 9.1G, utilisé à 17%
• /usr: 32G, utilisé à 32%
• /var: 14G, utilisé à 65%

Si on calcule vite fait, ça me fait ~21G utilisés, mais j'y ai quelques "gros" (plus de 100 megs) jeux qui traînent: red-eclipse 1.6, supertuxkart, ufo:ai, warmux, wesnoth… D'un autre côté, j'ai assez peu d'applications graphiques, notamment pas de DE "lourd".
Ce n'est pas optimisé, pas propre, pas vidé, je peux clairement faire mieux, quand le besoin est la (noyau + busybox + udev + dropbear + perl, et hop, un système qui tiens sur 1gig et qui est fonctionnel).

A comparer avec le seul dossier "windows" du PC du boulot, qui pèse 30G, et ça n'inclue pas la bureautique ni le navigateur je suppose. Encore moins des jeux :)
Point intéressant, c'est plut petit que dans mes souvenirs, ils ont fini par résoudre le problème des DLL stockées individuellement pour chaque version de chaque programme? Ou c'est peut-être que les gens qui gèrent mon PC ont mis un truc pour nettoyer… n'empêche que le gestionnaire de disque indique un usage complet de 80G alors que l'explorateur n'en trouve que 60, c'est louche. Je suppose qu'il faut que je fasse ça en tant qu'admin… la flemme.

avant Lennart, il y avait /bin + /sbin et /usr/bin

Oui, bon, lennart a bon dos quand même. Tu ne me feras pas croire qu'il arrive a aller sur toutes les machines qui utilisent un noyau linux pour aller modifier les partoches.
De toute façon, et ça fait quelques années maintenant, de nos jours le vrai / c'est dans l'initrd qui est.
A moins qu'il existe encore des distro qui permettent facilement de se passer d'initrd? Ca m'intéresse, j'avoue, parce que l'initrd de mes systèmes me semble généralement assez lent et gourmand. Je n'ai pas de mesure exacte cependant, mais je me souviens clairement avoir eu des VM Debian qui ne démarraient pas parce que l'initrd avait besoin de plus de 200 megs de ram, alors que le système une fois booté n'en utilise que 40… bon, vu que c'était pour le fun, j'ai juste rajouté de la ram, mais j'avoue que ça m'avait agacé.

The bare minimum hein… je te mets au défi de faire quoique ce soit avec ton windows, y compris de le faire marcher sur l'un de 3 ou 4 PC portables qui m'entourent.
Mais bon, j'aurai du préciser, je suppose, que je parlais d'avoir un système utilisable, pas de flamber. Et puis sérieux, 100 megs pour avoir juste le prompt de windows? Le bordel a même moins de fonctionnalités que ce bon vieux command.com du MS-DOS 6, genre, pas d'auto-completion même pour un vulgaire "echo"… même le prompt de UBoot est plus puissant (en même temps, contrairement à cmd.exe, UBoot n'est pas un jouet mais un outil)!

exiger d’un code dont le but principal est « être le plus performant possible » qu’il soit développé en respectant à la lettre des règles qui sont là pour garantir un souplesse d’évolution à toute épreuve,

Moui. Perso je dirais que l'abus d'héritage mène plus rapidement encore à un plat de spaghetti que l'usage de goto par contre, donc la maintenabilité et la souplesse quand on abuse de la POO et des dogmes, ben… je ne suis pas trop d'accord :)

Pour le 2, ça me gonflera toujours autant d'entendre 'tel langage est lent'.

Je ne vois pas ou est le problème de dire que le go est lent, pourtant?

Il me semble pourtant que depuis "quelques" années, l'héritage est considéré, à raison, comme étant un truc à éviter (sauf cas particuliers) parce que, entres autres:

• c'est lent (oui les vtables ont un coût)
• ce n'est pas aussi maintenable que ça en a l'air de prime abord: non, remonter une pile de 10 classes pour comprendre ce que fait une fonction, ce n'est pas cool

Après, il faut reconnaître que les exemples habituels pour la POO, et notamment celui des formes, sont catastrophiques.
Je ne crois pas qu'il soit vraiment utile de rappeler, par exemple, que les variables ça sert à quelque chose?
Donc, l'idée de faire deux classes différentes pour le carré et le rectangle? C'est débile. La seule raison que je vois, c'est si on a besoin de stocker une immense quantité de carrés, tellement immense que les 4 octets (voire moins) requis pour stocker la 2nd dimension aurait un réel impact sur les performances. Ce n'est pas franchement le cas le plus commun, perso ça ne m'est jamais arrivé. Je dirais donc que c'est débile de faire ça d'entrée de jeu, et que la raison la plus probable, c'est de faire de la merde pour filer un exemple bancal. Un carré est un rectangle, c'est tout. Pas la peine de chercher midi à quatorze heures comme on dit.

D'ailleurs, on peut vraiment décrire un triangle avec juste une hauteur et une largeur? Bien sûr que non! C'est encore un truc débile.
Un triangle requiers plus de données que ça.

Bref, en se basant sur des exemples débiles, c'est effectivement facile de démonter la POO. Ceci dit, je suis d'accord sur le fond: on a traversé plusieurs décennies ou la POO était présentée comme la panacée, et malheureusement on ne peut pas mettre à jour toutes les ressources du monde pour dire qu'en fait non, faire 5 couches d'héritage pour le fun, ce n'est pas une bonne architecture.
Perso, je vois l'héritage comme le goto: c'est utile, mais si on peut s'en passer, autant s'en passer. L'utiliser partout ou le bannir absolument, c'est du dogmatisme, et ça ne mène à rien de bon. C'est bien pour ça que j'apprécie C++ d'ailleurs: je fais de l'objet… si je veux, et si j'ai pas envie, j'en fait pas. En pratique, j'en utilise souvent, mais je n'ai pas souvenir d'avoir un seul programme qui soit de l'objet pur… j'ai toujours des fonctions qui se baladent, du code qui pourrait être mis en POO mais ça serait juste se faire chier pour rien, qui côtoie des objets avec plus ou moins (plutôt moins) de hiérarchie.

SI VOUS VOULEZ CHOUINER, VIENDEZ SUR LA TRIBUNE A 23H57 OU BIEN METTEZ UN COMMENTAIRE PERTINENT CA CHANGERA

Je me permets: CONNARD VA CHIER. T'AS VU? MOI AUSSI JE SAIS GUEULER COMME UN PUTOIS ET INSULTER TOUT LE MONDE!!!!

Plus sérieusement…

Désolé hein. Je comprend qu'on puisse aimer écrire a plusieurs mains (c'est à dire plus de deux, parce qu'a priori aucun humain n'en a plus de deux, et l'idée est d'avoir plusieurs cerveaux… bref) mais personnellement je me suis prêté à l'exercice une fois et je pense que ça a été improductif au final: la dépêche (une histoire de faire son DE soi même) avait été si modifiée dans le style et autres trucs sans que j'aie mon mot à dire, que ça m'a démotivé.

Pour être franc, je ne crois plus en les «communautés». Je suis toujours disposé à partager ce que je fait (avec les sources et l'historique), ça n'est pas lié. J'ai juste un problème avec la notion de collaboration, et ce, surtout quand l'auteur initial n'a aucun moyen de contrôle sur le devenir du texte.

BREF CONCLUSION: À L'AUTEUR DE CE JOURNAL (N'EMPÊCHE, BIEN PRATIQUE LE CAPS LOCKS): VA TE FAIRE VOIR AILLEURS, ICI ON RESPECTE LA NETIQUETTE IL ME SEMBLE! (dommage que ça soit pas une règle de modération j'imagine… si je me fais modérer pour ne pas le faire, je le comprendrais cela dis)

c'est plus clair, merci :)

Dans ce cas, un lien sur zulip serait intéressant. Ce qui le serait encore plus, c'est de développer le pourquoi tu ne comprend pas l'intérêt de discord (moi non plus je pige pas, mais bon, je suis vieux, j'utilise encore irc qui n'a toujours l'history qu'en draft pour la v3…)

Ouai, en gros haskell est juste à l'ouest: plus lent malgré le parallélisme, et bouffe le double de ram.
Ton message était censé promouvoir haskell, ou l'enfoncer?

Oh, d'un point de vue pragmatique, j'ai toujours un argument perso: je peux installer un OS sur moins de 50 gigs de stockage (avec, ou sans, la partition /home).
Sous windows, de ce que je vois au boulot (j'ai pas creusé, je suis plus ingé, on ne me demande plus de résoudre la racine des problèmes, juste les symptomes) il vaut mieux prévoir 150 gig pour la partoche système. Ca a un impact sur le coût du PC, l'air de rien… Je ne parle pas de la RAM ni du reste, hein. D'ailleurs, si j'en parlais, je dirais que je peux installer un OS complet et moderne sur 20 gigs de stockage sans le /home :)

Une autre raison: dans wiNdows il y a forcément un haine. Bon, ça, c'est fait, moi je suis plus la, salut …

Et du coup tu fais ça a chaque fois? Même si je comprend ton opinion (c'est moche, ils bossent pas pour rien) ils font un service gratos (vous êtes le produit) et promeuvent (sans le vouloir?) le LL.
Ma foi, je suis bien incapable de trouver un meilleur business model pour le libre.

Tu as oublié le plus important: pas d'installation, et pas de pré-requis dans la base de registre.
Franchement, la compilation… les utilisateurs s'en contre-branlent!

Il me semblait avoir compris que le terme portable du commentaire précédent avait un sens très différent que celui admis parmi les linuxiens

Je me souviens de mon passé de windowsien. Pour moi, une appli portable était… ben, un truc portable entres OS. Mais bon, j'étais déjà un codeur.

En fait, ici, le terme idéal serait: «une appli transportable» parce que c'est de ça qu'on parle. Pour être transportable, une appli ne doit pas nécessiter de traces dans le système sur lequel elle est utilisée. J'ai dit: nécessiter, ça veut dire que ça doit marcher sans installateur, mais pas forcément que ça ne doit pas laisser de traces (ça, c'est l'idéal, mais c'est techniquement impossible si l'OS décide d'espionner)

Je pense personnellement qu'il y a un sérieux problème en informatique: les soit-disant ingénieurs, qui sont plus des in-gêneurs, semblent faire leur maximum pour empêcher les gens d'utiliser leurs outils.
Evidemment ça ne concerne pas les gens qui obéissent aux ordres… quoique…

Aujourd'hui sur la route, ou c'était peut-être hier, j'ai entendu le type (titre: gouverneur je crois?) de la banque centrale française répondre au journaliste un truc du genre "ce qu'il faudrait avec les impôts, ce n'est ni les baisser, ni les monter, mais de la stabilité, parce que c'est la stabilité qui induit la confiance". Un truc dans ce goût la. Le monsieur m'a choqué (positivement) par son pragmatisme (et son objectivité apparente).
Je pense que cette idée n'est pas conne: la stabilité serait effectivement une bonne idée. Que ce soit pour les finances (son sujet, son problème) ou pour la sécurité informatique (le problème dont on parle, ici).
Si les interfaces pouvaient être constantes sur plus d'une décennie, je crois que ça mènerait à une bien meilleure amélioration de la sécurité informatique, ainsi qu'a une amélioration de la performance. Pourquoi? Parce qu'alors on passerait moins de temps a former les gens sur les trucs de base, pour se concentrer sur ce qui est important, et les gens, dont je fait partie, perdraient moins leur repères et seraient donc plus entraînés a repérer les irrégularités.

En gros, je crois que les principaux responsables de l'insécurité (et je ne le savait pas il y a 15 minutes) sont les gens qui produisent les OS. Si on… ah, c'est vrai, je ne suis plus dev de métier… si ils faisaient leur job pour la sécurité, alors ils arrêteraient de changer ces putain d'IHM tous les ans! Aussi con que ça puisse paraître, OUI, C'EST LIÉ!