freem a écrit 4916 commentaires

Pour info, https://intelligence-artificielle.developpez.com/actu/342714 passe. En fait, vu l'URI, j'ai supposé que leur BDD n'utilise pas le texte comme indice, mais le numéro juste avant. J'ai probablement deviné juste. Ou pas, je ne peux pas vérifier. Mais bon: ça marche :)

En même temps avec un OS digne de ce nom, il suffit de mettre caps lock, ce n'est pas si difficile :)

Le coeur du système sous Debian n'utilise pas bash, mais dash. Il est très probable que ça s'applique aussi à ses dérivées.
Je sais que bash est toujours un paquet essentiel, et je n'ai pas encore fait l'effort de forcer debian à le virer pour le fun, mais j'ai le sentiment que c'est surtout historique.

Quant à Grub, ma foi, pour moi il ne fait pas partie de l'OS. D'ailleurs je nai jamais supporté grub2, heureusement qu'il y a toujours eu le choix de ne pas l'utiliser, moi ça ne m'a apporté que des emmerdes grub.

Vu comment ça marche super bien le déploiement des logiciels en milieu pro sous windows… de mon peu d'expérience, y'a environ 15% des installs qui foirent, les install ne sont pas en parallèle (sous debian non plus cela dit) et le tout est d'une lenteur telle que pour avoir un système fonctionnel après un "PC refresh" il vaut mieux tabler sur une journée, une demi si on a de la chance!

Alors que je me souviens avoir pondu une config pxe qui faisait une install (de debian) automatisée en moins de 30 minutes, avec tout configuré une et une seule fois, et tous les paquets à jour…

Non, vraiment, du point de vue du déploiement, jusqu'à présent je n'ai jamais vu de windows s'installer facilement ou même juste rapidement.

La sortie de ls ne va pas changer de si tôt, ça casserait énormément de scripts

Il me semble que ça s'est produit il y a peu, chez GNU.

J'ai toujours comparé PowerShell à un langage comme Python plutôt qu'a un shell comme Bash. Je n'ai pas l'impression que les utilisateurs de PowerShell tape de la ligne de commande a longueur de journée, et me semble plus adapté à l'écriture de scripts.

+1. PowerShell n'est pas franchement adapté à utilisation interactive, je suis bien d'accord. Mais il peut être utilisé ainsi.

L'approche des shells "classiques" me parait plus flexible et plus facilement extensible que PowerShell, avec une approche "gestion de flux".

Justement, le powershell en faisant passer des objets développe la gestion de flux pour moi. Tout fonctionne toujours via du pipe en série après tout.
Mon avis sur PS est compliqué, parfois je l'aime parfois je le hais, mais bon, je n'ai pas assez l'occasion de le pratiquer. Je pense quand même dans l'ensemble qu'il est plutôt bien foutu. Si seulement windows avait un éditeur de texte et un émulateur de terminal potables, ça serait p'tet plus intéressant…

Parce que c'est un exemple de nom comme un autre, mais tu as raison de rappeller qu'il ne fait pas utiliser ls dans un script, notamment parce que son interface n'est pas standard, ni celle d'entrée, ni celle de sortie, donc au moindre changement d'upstream ça peut péter le script.
Avec ls, il faut parser la sortie, et parser du texte c'est très difficile (sisi, c'est très difficile, il suffit de penser a tout ce qu'il faut gérer, unicode arrivant en 1er). Surtout que cette commande n'a pas été faite pour être parsée, malheureusement.

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