C'est un peu le problème avec cette tendance à vouloir tout réécrire. Une fois passée la hype il n'y a plus grand monde. En attendant, GNU ls est toujours maintenu 30 ans après :)
Personnellement, j'utilise exa depuis quelques années, j'en suis très content, je devrais migrer sur eza, et j'ai plein de trucs à faire avant. On verra.
GNU coreutils, c'est très bien pour cette stabilité, en effet.
L’intérêt de ce genre de projet (le premier) me laisse perplexe. Ce sont des programmes qui ne bénéficient pas des avantages de rust (mon ls peux leaker comme un goret je ne m'en rendrais jamais compte).
Pour les outils comme lsd ou exa, ils font des choses en plus, avec pleins de couleurs. C'est vraiment autre chose qu'une réécriture. J'en utilise certains, mais pas parce qu'il sont en écrit en rust (ça pourrait être du python ou du pascal)
Je veux bien être trop vieux pour apprécier, mais est-ce bien raisonnable d'atteindre une telle taille de binaire (ls ne fait que 148k) ? Ce n'est pas qu'une question d'espace disque et de Ram occupée puisque les ordis actuels en ont plus qu'il n'en faut1. Mais je me demande quelles failles de sécurité ou quels défauts du disque se cachent dans la taille—gigantesque—de ce petit utilitaire de base. N'y a-t-il pas trop de «trucs mieux» là-dedans ?
sauf quand tout plante et que l'occupation mémoire grimpe rapidement, on est alors bien content de pouvoir lancer un petit utilitaire de rien du tout ↩
Posté par cg .
Évalué à 3.
Dernière modification le 09 septembre 2023 à 14:58.
Eza (815Ko sur mon ordi) est en Rust, c'est à dire qu'il contient toutes les libs dont il dépend. Faudrait comparer avec un build statique de ls (flemme totale là).
Busybox fait 1.3Mo de son côté :p.
Et tomsrtbt 1.7Mo *<:o)
exa (version debian) chez moi fait 856 ko (contre 136 pour ls), eza (téléchargé sur le dépôt github officiel) fait 1328 ko, les 2 premiers ont 5 dépendances (linux-vdso.so.1 libgcc_s.so.1 libm.so.6 libc.so.6 ld-linux-x86-64.so.2) tandis que eza en a 8, donc ça ne me semble pas complètement statique.
Effectivement chez moi busybox est plus impressionnant, car il fait un peu plus de 2 Mo mais il complètement statique
exa c'est sympa, le rendu couleur est un peu plus complet que ls, mais je crois que je vais rester sur ls quand même…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
Tout à fait, busybox est entièrement statique. Par contre, faut pas le comparer à ls (ou autre) car Bb est la somme de ses applets qui sont inséparables…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Si je ne dis pas de connerie, GNU coreutils ne dépend que de libc + GNUlib.
GNUlib est static, et libc est aussi une dépendance des packages Rust. (Oui, elle est désactivable, mais généralement par défaut non)
Donc dans ce cas, la comparaison est plutôt équivalente.
De manière générale, les packages Rust, ont tendance à contenir beaucoup plus de dépendances que les packages C, principalement dû à la manière donc la gestion de dépendances marche en Rust, qui tire des dépendances, qui tire des dépendances… (mais par contre est facile)
En C, la gestion de dépendances, c'est chiant, mais vu que c'est chiant, bah, on évite d'en avoir trop, surtout quand ce sont des bibliothèques pas très rependues.
Les caches qui font tampons entre les registres et la RAM ne sont pas si gros que ça. Qui plus est il y a le coût associé à l’appel exec du programme qui doit être pris en compte.
Même si ce n’est pas trop le cas de ls (exclusif d’un mode d’utilisation intéractif, car on lui préfèrera find — 213ko pour la version gnu), nombre d’utilitaires doivent être pensés pour être utilisables dans des contextes de traitement de masse, sur des machines très chargées, etc.
Bref, des gamins qui font des jouets, plutôt que du travail d’informaticiens exigeants et rigoureux.
Bref, des gamins qui font des jouets, plutôt que du travail d’informaticiens exigeants et rigoureux.
Non des gens qui savent où se trouve la qualité de leur logiciel et ne croient pas que leur logiciel est ce qu'il n'est pas.
exa ou eza ne sont pas fait pour lister les fichiers de ton grille pain. C'est un compagnon dans l'usage du terminal comme gestionnaire de fichiers.
eza n'aura jamais la performance d'un ls ce n'est pas son but, mais il fait plus de choses comme comprendre l'état git de ton dossier et ça ça ralenti bien plus le logiciel que d'essayer de regarder ce qu'il se passe dans le cache de ton cpu.
Par contre pour les utilisateurs pouvoir en un seul exécutable avoir des informations qui habituellement réclament l'appel à différents programmes c'est plus léger et bien plus performant, mais surtout plus pratique.
Juger un logiciel sans le comprendre en dis plus long sur le juge que sur le logiciel. Juger les personnes qui sont derrière le logiciel n'a pas sa place ni ici ni nul part ailleurs. Faut vraiment faire un travail sur toi même pour vivre en société et respecter ce qui t'entourent.
exa ou eza ne sont pas fait pour lister les fichiers de ton grille pain. C'est un compagnon dans l'usage du terminal comme gestionnaire de fichiers.
eza n'aura jamais la performance d'un ls ce n'est pas son but, mais il fait plus de choses comme comprendre l'état git de ton dossier et ça ça ralenti bien plus le logiciel que d'essayer de regarder ce qu'il se passe dans le cache de ton cpu.
Par contre pour les utilisateurs pouvoir en un seul exécutable avoir des informations qui habituellement réclament l'appel à différents programmes c'est plus léger et bien plus performant, mais surtout plus pratique.
+1
Par contre je m'interroge sur la pertinence d'utiliser trouzemille outils qui ne seront majoritairement pas sur les serveurs bien souvent cantonné à Vi. En local bien entendu si c'est récurent.
J'utilise pas eza, mais j'utilise ce genre d'outils (des plus ou moins alternatives à des outils standards, mais bardés de fonctionnalités). J'utilise plus souvent un shell en local que sur serveur. Je n'utilise pas de gestionnaire de fichier à la place j'ai urxvt + zsh + des outils. Généralement les serveurs je ne les manipules presque qu'avec ansible.
Tu as un paquets d'outils comme ça qui n'ont jamais eu vocation à aller sur serveur ou dans de l'embarquer à commencer par sl par exemple.
Tu as un paquets d'outils comme ça qui n'ont jamais eu vocation à aller sur serveur ou dans de l'embarquer à commencer par sl par exemple.
Et pourtant, j’ai vu sl très souvent installé sur des serveurs (« Oui mais comme ça c’est rigolo quand tu te plantes en tapant ls… »)
Cela dit de mon point de vue, le problème sur les serveurs c’est pas tellement ce genre d’outil, mais ces logiciels qui partent du principe que tu dois build directement sur le serveur de production et donc que tu dois y récupérer les sources et y installer les outils de build.
Posté par Psychofox (Mastodon) .
Évalué à 4.
Dernière modification le 11 septembre 2023 à 13:30.
Moi je préfère cette fonction que j'ai ajouté à mon .bashrc :
sl(){# Derivative work (script to function) of sl bash script# https://gir.st/blog/sl-alt.htm# Copyright (C) 2018 - Tobias Girstmair## This program is free software: you can redistribute it and/or modify# it under the terms of the GNU General Public License as published by# the Free Software Foundation, either version 3 of the License, or# (at your option) any later version.## This program is distributed in the hope that it will be useful,# but WITHOUT ANY WARRANTY; without even the implied warranty of# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the# GNU General Public License for more details.## You should have received a copy of the GNU General Public License# along with this program. If not, see <https://www.gnu.org/licenses/>.LEN=$(ls "$@"| wc -L)# get the length of the longest line
ls "$@"| rev |whileread -r line;doprintf"%${LEN}.${LEN}s\\n""$line"| sed 's/^\(\s\+\)\(\S\+\)/\2\1/'done}
Juger un logiciel sans le comprendre en dis plus long sur le juge que sur le logiciel. Juger les personnes qui sont derrière le logiciel n'a pas sa place ni ici ni nul part ailleurs. Faut vraiment faire un travail sur toi même pour vivre en société et respecter ce qui t'entourent.
Je méprise copieusement les gens de ton genre, qui appliquent un double-standard et qui exigent des autres ce qu’ils n’appliquent pas à eux-même. Quant au fond tu tentes de m’expliquer ce que je sais déjà, du haut de ton égo ; si seulement tu avais lu mon commentaire tu n’aurais pas eu à prendre cette peine.
Je méprise copieusement les gens de ton genre, qui appliquent un double-standard et qui exigent des autres ce qu’ils n’appliquent pas à eux-même.
De quel double standard parle-tu ?
Quant au fond tu tentes de m’expliquer ce que je sais déjà, du haut de ton égo ; si seulement tu avais lu mon commentaire tu n’aurais pas eu à prendre cette peine.
Si tu le sait déjà comment peux-tu te permettre de traiter des gens de gamins par exemple ?
Tu sembles nouveau ici, je pense que tu devrais réviser ta manière d'interagir sur les commentaires de ce site, quelque soit l'intérêt (ou non) de tes avis sur le fond.
# …please use the active fork eza instead
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 7.
https://github.com/eza-community/eza
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: …please use the active fork eza instead
Posté par Xanatos . Évalué à 2.
[^] # Re: …please use the active fork eza instead
Posté par mousquetaire G2 . Évalué à 4.
& eza is a replacement for exa
[^] # Re: …please use the active fork eza instead
Posté par jseb . Évalué à 7.
is a modern replacement for exa
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
# Avez-vous envisagé de le réécrire en…
Posté par Julien Jorge (site web personnel) . Évalué à 10.
C'est un peu le problème avec cette tendance à vouloir tout réécrire. Une fois passée la hype il n'y a plus grand monde. En attendant, GNU ls est toujours maintenu 30 ans après :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Avez-vous envisagé de le réécrire en…
Posté par Glandos . Évalué à 6.
Oui : https://github.com/uutils/coreutils/tree/main/src/uu/ls (réécriture des coreutils en Rust)
Oui : https://github.com/lsd-rs/lsd vendu comme The next gen ls command
Personnellement, j'utilise exa depuis quelques années, j'en suis très content, je devrais migrer sur eza, et j'ai plein de trucs à faire avant. On verra.
GNU coreutils, c'est très bien pour cette stabilité, en effet.
[^] # Re: Avez-vous envisagé de le réécrire en…
Posté par Lutin . Évalué à 5.
L’intérêt de ce genre de projet (le premier) me laisse perplexe. Ce sont des programmes qui ne bénéficient pas des avantages de rust (mon ls peux leaker comme un goret je ne m'en rendrais jamais compte).
Pour les outils comme lsd ou exa, ils font des choses en plus, avec pleins de couleurs. C'est vraiment autre chose qu'une réécriture. J'en utilise certains, mais pas parce qu'il sont en écrit en rust (ça pourrait être du python ou du pascal)
# Je suis vieux
Posté par Pinaraf . Évalué à 8.
Quand j'ai vu le titre, je me suis dit «ben… évidemment que ce n'est plus maintenu, ça fait des années»
Puis j'ai du cliquer pour voir qu'on ne parlait pas du tout de https://www.x.org/releases/current/doc/man/man4/exa.4.xhtml
[^] # Re: Je suis vieux
Posté par aiolos . Évalué à 4.
Ah, merde, pareil ! Je me suis dit << Ben, c'était prévu pour être transitoire ! >>
# taille de binaire
Posté par orfenor . Évalué à 3.
Je veux bien être trop vieux pour apprécier, mais est-ce bien raisonnable d'atteindre une telle taille de binaire (
ls
ne fait que 148k) ? Ce n'est pas qu'une question d'espace disque et de Ram occupée puisque les ordis actuels en ont plus qu'il n'en faut1. Mais je me demande quelles failles de sécurité ou quels défauts du disque se cachent dans la taille—gigantesque—de ce petit utilitaire de base. N'y a-t-il pas trop de «trucs mieux» là-dedans ?sauf quand tout plante et que l'occupation mémoire grimpe rapidement, on est alors bien content de pouvoir lancer un petit utilitaire de rien du tout ↩
[^] # Re: taille de binaire
Posté par BAud (site web personnel) . Évalué à 1.
ah chez moi, moins :-)
[^] # Re: taille de binaire
Posté par cg . Évalué à 3. Dernière modification le 09 septembre 2023 à 14:58.
Eza (815Ko sur mon ordi) est en Rust, c'est à dire qu'il contient toutes les libs dont il dépend. Faudrait comparer avec un build statique de
ls
(flemme totale là).Busybox fait 1.3Mo de son côté :p.
Et tomsrtbt 1.7Mo *<:o)
(sur Archlinux exa est un lien vers eza)
[^] # Re: taille de binaire
Posté par zurvan . Évalué à 5.
exa (version debian) chez moi fait 856 ko (contre 136 pour ls), eza (téléchargé sur le dépôt github officiel) fait 1328 ko, les 2 premiers ont 5 dépendances (linux-vdso.so.1 libgcc_s.so.1 libm.so.6 libc.so.6 ld-linux-x86-64.so.2) tandis que eza en a 8, donc ça ne me semble pas complètement statique.
Effectivement chez moi busybox est plus impressionnant, car il fait un peu plus de 2 Mo mais il complètement statique
exa c'est sympa, le rendu couleur est un peu plus complet que ls, mais je crois que je vais rester sur ls quand même…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: taille de binaire
Posté par cg . Évalué à 4.
Bien vu, j'ai même pas pensé à vérifier ! En effet les dépendances de libs C/C++ sont dynamiques.
[^] # Re: taille de binaire
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Tout à fait,
busybox
est entièrement statique. Par contre, faut pas le comparer àls
(ou autre) car Bb est la somme de ses applets qui sont inséparables…“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: taille de binaire
Posté par uso (site web personnel) . Évalué à 3.
Si je ne dis pas de connerie, GNU coreutils ne dépend que de libc + GNUlib.
GNUlib est static, et libc est aussi une dépendance des packages Rust. (Oui, elle est désactivable, mais généralement par défaut non)
Donc dans ce cas, la comparaison est plutôt équivalente.
De manière générale, les packages Rust, ont tendance à contenir beaucoup plus de dépendances que les packages C, principalement dû à la manière donc la gestion de dépendances marche en Rust, qui tire des dépendances, qui tire des dépendances… (mais par contre est facile)
En C, la gestion de dépendances, c'est chiant, mais vu que c'est chiant, bah, on évite d'en avoir trop, surtout quand ce sont des bibliothèques pas très rependues.
[^] # Re: taille de binaire
Posté par greendev . Évalué à -10.
Les caches qui font tampons entre les registres et la RAM ne sont pas si gros que ça. Qui plus est il y a le coût associé à l’appel
exec
du programme qui doit être pris en compte.Même si ce n’est pas trop le cas de
ls
(exclusif d’un mode d’utilisation intéractif, car on lui préfèrerafind
— 213ko pour la version gnu), nombre d’utilitaires doivent être pensés pour être utilisables dans des contextes de traitement de masse, sur des machines très chargées, etc.Bref, des gamins qui font des jouets, plutôt que du travail d’informaticiens exigeants et rigoureux.
[^] # Re: taille de binaire
Posté par barmic 🦦 . Évalué à 10.
Non des gens qui savent où se trouve la qualité de leur logiciel et ne croient pas que leur logiciel est ce qu'il n'est pas.
exa ou eza ne sont pas fait pour lister les fichiers de ton grille pain. C'est un compagnon dans l'usage du terminal comme gestionnaire de fichiers.
eza n'aura jamais la performance d'un ls ce n'est pas son but, mais il fait plus de choses comme comprendre l'état git de ton dossier et ça ça ralenti bien plus le logiciel que d'essayer de regarder ce qu'il se passe dans le cache de ton cpu.
Par contre pour les utilisateurs pouvoir en un seul exécutable avoir des informations qui habituellement réclament l'appel à différents programmes c'est plus léger et bien plus performant, mais surtout plus pratique.
Juger un logiciel sans le comprendre en dis plus long sur le juge que sur le logiciel. Juger les personnes qui sont derrière le logiciel n'a pas sa place ni ici ni nul part ailleurs. Faut vraiment faire un travail sur toi même pour vivre en société et respecter ce qui t'entourent.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: taille de binaire
Posté par Xanatos . Évalué à 1.
+1
Par contre je m'interroge sur la pertinence d'utiliser trouzemille outils qui ne seront majoritairement pas sur les serveurs bien souvent cantonné à Vi. En local bien entendu si c'est récurent.
[^] # Re: taille de binaire
Posté par barmic 🦦 . Évalué à 2.
J'utilise pas eza, mais j'utilise ce genre d'outils (des plus ou moins alternatives à des outils standards, mais bardés de fonctionnalités). J'utilise plus souvent un shell en local que sur serveur. Je n'utilise pas de gestionnaire de fichier à la place j'ai urxvt + zsh + des outils. Généralement les serveurs je ne les manipules presque qu'avec ansible.
Tu as un paquets d'outils comme ça qui n'ont jamais eu vocation à aller sur serveur ou dans de l'embarquer à commencer par
sl
par exemple.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: taille de binaire
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2.
Et pourtant, j’ai vu
sl
très souvent installé sur des serveurs (« Oui mais comme ça c’est rigolo quand tu te plantes en tapantls
… »)Cela dit de mon point de vue, le problème sur les serveurs c’est pas tellement ce genre d’outil, mais ces logiciels qui partent du principe que tu dois build directement sur le serveur de production et donc que tu dois y récupérer les sources et y installer les outils de build.
La connaissance libre : https://zestedesavoir.com
[^] # Re: taille de binaire
Posté par Psychofox (Mastodon) . Évalué à 4. Dernière modification le 11 septembre 2023 à 13:30.
Moi je préfère cette fonction que j'ai ajouté à mon .bashrc :
[^] # Re: taille de binaire
Posté par Psychofox (Mastodon) . Évalué à 3.
Moi je me fais encore pas mal de fois avoir en voulant éditer un fichier avec vi et en tapant nvim sur une machine distante ;-)
[^] # Re: taille de binaire
Posté par greendev . Évalué à -10.
Je méprise copieusement les gens de ton genre, qui appliquent un double-standard et qui exigent des autres ce qu’ils n’appliquent pas à eux-même. Quant au fond tu tentes de m’expliquer ce que je sais déjà, du haut de ton égo ; si seulement tu avais lu mon commentaire tu n’aurais pas eu à prendre cette peine.
[^] # Re: taille de binaire
Posté par barmic 🦦 . Évalué à 4.
De quel double standard parle-tu ?
Si tu le sait déjà comment peux-tu te permettre de traiter des gens de gamins par exemple ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: taille de binaire
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 4.
(juste pour dire que j’ai liké par mégarde avec mes gros doigts) (oui, d’habitude on s’excuse dans l’autre sens, je sais)
La connaissance libre : https://zestedesavoir.com
[^] # Re: taille de binaire
Posté par Psychofox (Mastodon) . Évalué à 9.
Tu sembles nouveau ici, je pense que tu devrais réviser ta manière d'interagir sur les commentaires de ce site, quelque soit l'intérêt (ou non) de tes avis sur le fond.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.