Il y a maintenant une quinzaine jours, j'ai entrepris l'écriture d'un petit utilitaire se voulant une alternative au fameux df(1).
J'ai d'abord commencé le développement avec comme objectif mon propre plaisir à développer puis je me suis vite rendu compte qu'il se trouvait des personnes intéressées par ce projet.
Les versions se sont succédées à un rythme soutenu jusqu'à la version 2.3.0 sortie aujourd'hui. J'ai estimé que la maturité de ce programme était maintenant suffisante afin de mériter une dépêche et de le faire connaître aux personnes pouvant potentiellement être intéressées.
Qu'apporte dfc(1) que ne propose pas déjà df(1)? En voici la liste :
- Gestion des couleurs avec modes automatique, toujours et jamais (similaire à ce que l'on peut trouver dans les commandes ls(1) et grep(1)).
- Affichage d'un graphe montrant le taux d'utilisation des disques.
- Possibilité d'afficher les options de montage.
- Ajustement automatique de l'affichage en fonction de la taille du terminal.
En plus de ces options, dfc(1) gère également une fonction de filtrage par type de système de fichiers (inclusion et exclusion), le choix de l'unité de mesure pour l'affichage (human-readable, Kio, Ko, Gio, etc.), le décompte du nombre d'inodes, la somme des données (y compris les inodes si l'option est activée) et l'affichage du type de système de fichiers.
Pour l'instant, dfc(1) ne fonctionne que sur GNU/Linux mais un portage est en cours pour prendre en charge notamment FreeBSD et le portage vers d'autres plate-formes (autres *BSD et OSX) devrait se faire à plus ou moins moyen-terme.
Aller plus loin
- Site du projet (3098 clics)
- Annonce de la version 2.3.0 (186 clics)
- Wiki (451 clics)
- Manpage (154 clics)
# beaucoup trop gros
Posté par lathan . Évalué à 4.
ça passera pas
[^] # Re: beaucoup trop gros
Posté par Faya . Évalué à 5.
Et pourtant :
Très pratique, félicitations !
[^] # Re: beaucoup trop gros
Posté par rewind (Mastodon) . Évalué à 8.
Question : comment on peut arriver à une version 2.3.0 après 15 jours de développement ? Là, ça dépasse la numérotation de Firefox et Chrome réuni :D
[^] # Re: beaucoup trop gros
Posté par Krunch (site web personnel) . Évalué à 5.
Il essai peut-êtde de faire comme certaines sociétés qui commencent le numéro de version de tous leurs produits à 2.1 pour faire croire que c'est stable.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: beaucoup trop gros
Posté par Rolinh (site web personnel) . Évalué à 4.
Heu… regarde les commits dans le dépôt git?
Sinon, tu peux aussi afficher l'historique des versions dans la section "roadmap" du site et voir les changements apportés à chaque version. Ou encore, lire les annonces que j'ai rédigé pour chaque version.
Tu as le choix. ;)
Mais bon, dfc c'est grosso-modo 1200-1300 lignes de C, pas plus, donc y ajouter une fonctionnalité n'est pas comparable à ajouter une fonctionnalité à Firefox ou Chromium.
Pour continuer dans le rythme, je peux déjà dire que la 2.4.0 ne devrait pas trop tarder et apportera le support officiel de FreeBSD (merci à un lecteur de linuxfr!!).
Enfin bon, ce rythme tend à ralentir maintenant que la plupart des choses que je voulais ajouter l'ont étés. ;)
[^] # Re: beaucoup trop gros
Posté par rewind (Mastodon) . Évalué à 7.
8 versions en 13 jours, ça fait une version toutes les 39 heures ! À un moment, ça n'a plus de sens ces versions. Il ne faut pas mal le prendre, mais je pense qu'il faut revoir ton système de release et t'inspirer de ce qui se fait ailleurs. Par exemple, Go, au départ, il faisait une release par semaine, mais personne n'arrivait à suivre. Du coup, ils ont fait des releases plus espacées, tout en conservant des pseudo-releases toutes les semaines.
C'est bien de fournir des versions qui marchent régulièrement (release often), mais il ne faut pas pour autant en faire des versions majeures comme tu le fais. Imagine qu'un packageur veuille introduire ton logiciel dans une distribution, il aura à peine le temps de faire son paquet et de le soumettre qu'il y aura déjà 2 ou 3 autres versions, ce n'est pas gérable.
[^] # Re: beaucoup trop gros
Posté par Rolinh (site web personnel) . Évalué à 1.
Ta remarque est très pertinente mais de toute façon, je ne vais pas avoir le temps de continuer à ce rythme. ;)
Les prochaines versions devraient être beaucoup plus espacées dans le temps maintenant que les fonctions principales que je souhaitais sont intégrées.
[^] # Re: beaucoup trop gros
Posté par William Steve Applegate (site web personnel) . Évalué à 3.
Pourtant, il y a des précédents :
Envoyé depuis mon PDP 11/70
[^] # Re: beaucoup trop gros
Posté par Bapt (site web personnel) . Évalué à 6.
et puis sérieux qu'est ce qu'on s'en fout le dev estime que c'est bien de fournir une nouvelle version il la fournit c'est tout.
[^] # Re: beaucoup trop gros
Posté par CHP . Évalué à 4.
Comme le fameux "release often, release early" ?
Ou bien encore comme Linus qui faisait parfois plusieurs release par jour, aux débuts de Linux ?
Il travaille beaucoup, il release souvent, il a raison.
[^] # Re: beaucoup trop gros
Posté par Bapt (site web personnel) . Évalué à 4.
pour ceux que ça intéresse la version 2.4.0 est dispo dans FreeBSD: sysutils/dfc http://www.freshports.org/sysutils/dfc/ il manque juste le support des options de montage (EFLEMME) mais je le ferai plus tard.
[^] # Re: beaucoup trop gros
Posté par Tonton Th (Mastodon) . Évalué à 3.
Bah si, c'est passé. un df(1) rempli de cloches et de sifflets, je trouve ça superfun, et donc je vais regarder ce qu'on peut en faire sur
sparc64/openbsd. Un bon projet pour me re-donner envie de coder, du futile avec de la technologie dedans, ça réveille. J'aime le poisson et je mange des tièlles Dassé.# Dépend du terminal ?
Posté par koxinga . Évalué à 1.
Je viens d'installer dfc 2.3.0 (sous Archlinux) et le graphe n'apparait pas quand je suis dans un xterm, dans le Terminal de xfce ou en tty (donc dfc et dfc -b donnent exactement le même résultat). Par contre, j'ai bien un graphe avec konsole.
[^] # Enlarge your... terminal.
Posté par Arthur Accroc . Évalué à 4.
Pareil.
J’ai le graphe dans les trois cas… si le terminal est assez large. Si je le laisse en 80 colonnes, il n’y a effectivement pas de graphe. À 81, les graphes apparaissent et il y a un espace après mon point de montage le plus long (donc ça aurait pu rentrer tout juste dans 80 avec le problème de ne pas avoir deux retours à la ligne après cette ligne).
Sinon, sympa comme petit utilitaire, mais où est le poisson d’avril ?
C’est un cheval de Troie qui envoie l’occupation de mon disque aux RG ?
À part ça, dans le man :
Pour moi, ça devrait être « may » plutôt que « can ».
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Enlarge your... terminal.
Posté par Rolinh (site web personnel) . Évalué à 3. Dernière modification le 01 avril 2012 à 19:13.
Oui, le comportement consiste à ne pas afficher le graphe lorsque la largeur du terminal est
<=80. Dans ton cas, cela laisse peut-être un espace et l'affichage aurait été correct cependant la largeur pouvant varier énormément en fonction des points de montage, ce n'est pas forcément le cas. Il y a toujours l'option -f au cas où.Tu as parfaitement raison pour le man. Je vais corriger cela.
Et puis non, non, pas de poisson d'avril ni de trojan (tu peux aller voir les sources, le tout étant sous licence BSD). J'avais écris la dépêche hier sans penser qu'aujourd'hui on était le premier avril! Et je n'avais d'ailleurs pas tout de suite compris le premier commentaire…
[^] # Re: Dépend du terminal ?
Posté par Rolinh (site web personnel) . Évalué à 2.
Tu es sûr que ce n'est pas une question de largeur de ton terminal?
Chez moi cela fonctionne parfaitement, que ce soit avec xterm, le Terminal de Xfce, le tty ou encore rxvt-unicode.
Si jamais, il y a toujours l'option -f. Si le problème ne vient pas de là, alors c'est qu'il doit y avoir un bug.
[^] # Re: Dépend du terminal ?
Posté par koxinga . Évalué à 3.
En effet, c'était un problème de largeur de terminal, je peux voir les graphes avec l'option -f. Pour le coup, c'est dommage de placer la limite par défaut à 80 exclus, c'est quand même une valeur courante. Pourquoi ne pas calculer la taille nécessaire et afficher si possible ? Chez moi cela tient sur une ligne de 69 caractères.
Bon allez, alias df="dfc -f" et j'arrête de t'embêter.
[^] # Re: Dépend du terminal ?
Posté par Rolinh (site web personnel) . Évalué à 1.
Le problème c'est que si je change cette limite, cela pourrait casser l'affichage chez d'autres personnes (spécialement si l'option -i est activée).
Cela serait possible de faire un calcul de la taille nécessaire mais… je ne suis pas sur que le jeu en vaille la chandelle. Enfin, si quelqu'un me propose un patch correct, je l'accepte volontiers. :)
[^] # Re: Dépend du terminal ?
Posté par koxinga . Évalué à 3.
Ce que je ne comprends pas, c'est qu'avec un terminal à 81 caractères de large, l'affichage est déjà "cassé" avec un "dfc -i". Ces limites magiques à 81, 125 et 151 ne me semblent pas une bonne solution.
Bon, j'ai un peu la flemme de faire un patch, mais j'ai jeté un coup d’œil à ton code, donc quelques commentaires :
- Vu que tu stockes déjà la longueur maximale du filesystem, du répertoire de montage et du type pour le padding, cela ne devrait pas être compliqué de calculer la taille nécessaire pour tout afficher. Le reste a l'air de taille constante ? (en passant, il faudrait probablement nettoyer le code d'affichage de taille totale et utilisée). Du coup, tu peux changer l'affichage par défaut entre fetch_info et disp au lieu de choisir tout au début.
- Tu ne te sers pas de dirmaxlen ? Cela provoque des problèmes quand on veut les options de montage alors que le nom de dossier est long
[^] # Re: Dépend du terminal ?
Posté par Rolinh (site web personnel) . Évalué à 2.
Je suis d'accord que ces limites ne sont pas forcément optimales.
Merci pour tes remarques, j'en tiendrais compte pour l'avancement de dfc.
[^] # Re: Dépend du terminal ?
Posté par Katyucha (site web personnel) . Évalué à 2.
J'ai bien les graphes mais la longueur des champs pose un problème :
+/mapper/rootvg-varcache [****---------------] 24% 761.9M 1.0G /var/cache
+ev/mapper/rootvg-varlog [*------------------] 9% 1.8G 2.0G /var/log
Il me manque quelques lettres… bien dommage
Sinon, j'adore :)
[^] # Re: Dépend du terminal ?
Posté par Rolinh (site web personnel) . Évalué à 2.
Merci :)
Oui, les champs trop long sont tronqués afin de ne pas perturber l'affichage. Je vais ajouter une option permettant de ne pas les tronquer (mais cela nécessite plus de place pour être affiché à l'écran).
[^] # Re: Dépend du terminal ?
Posté par Katyucha (site web personnel) . Évalué à 1.
Merci ! je vais attendre cette version pour la proposer aux collegues :)
[^] # Re: Dépend du terminal ?
Posté par Rolinh (site web personnel) . Évalué à 1.
Cette option est maintenant disponible (version 2.5.0).
Il s'agit de -W ;)
[^] # Re: Dépend du terminal ?
Posté par Katyucha (site web personnel) . Évalué à 1.
Au poil :)
Compilé, packagé en RPM, farpait !
# C'est bien, ça !
Posté par Sébastien Rohaut . Évalué à 2.
J'aime bien ce truc, un peu dans la lignée de glances. Bon travail.
# Très bon
Posté par littlebreizhman . Évalué à 4.
Fait parfaitement son job.
Installé en 2 secondes depuis l'archive.
J'adore tous les outils de ce genre qui mettent un peu de fun dans le terminal et qui facilite la vie.
[^] # Re: Très bon
Posté par Zylabon . Évalué à 3.
Pareil, pour moi, c'est adopté !
C'est bien tout ces logiciels qui sont des nouvelles implémentations de soft unix. Comme htop, byobu, heuuuuuu… dfc ! À conditions qu'ils apportent quelque chose. Quoi que byobu c'est un mauvais exemple.
Merci beaucoup !
Please do not feed the trolls
[^] # Re: Très bon
Posté par tragikomik . Évalué à 2.
Merci pour le travail, logiciel adopté!
# Compatibilité avec df
Posté par THE_ALF_ . Évalué à 8.
Simple et efficace, j'adopte, merci :)
Un petit bémol: pour pouvoir être utilisé correctement en remplacement de df, il serait intéressant que df et dfc utilisent les mêmes options en ligne de commande. Typiquement, 'df -h' affiche le mode "human readable", alors que dfc affiche l'aide. Ce genre de différence de comportement peut poser des problèmes lorsque l'on a un alias de df vers dfc.
Raphaël
[^] # Re: Compatibilité avec df
Posté par Rolinh (site web personnel) . Évalué à 1.
Ce ne sera pas le cas en raison de certains choix que j'ai effectués.
La première chose, c'est que l'affichage par défaut de dfc(1) utilise le format "human-readable". Je trouvais cela pertinent étant donné que la plupart du temps ces données sont lues par… des humains. Donc une option -h n'a pas tellement de sens.
L'autre raison vient du fait que df(1) utilise les options longues qui sont possibles en utilisant getopt_long(3) mais cette dernière est une extension GNU et je ne l'utilise pas (je me contente de getopt(3) et getsubopt(3)).
Pour le reste des options, elles sont quand même relativement similaires:
-a pour l'affichage de systèmes de fichiers pas forcément pertinent
-t pour filtrer en fonction du type
-T pour l'affichage du type de système de fichiers
C'est vrai que du coup, j'utilise par exemple -s au lieu de --total pour faire la somme mais de nouveau, c'est en raison de la non-utilisation d'options longues.
Bref, le mieux serait peut-être de ne pas faire d'alias vers df?
[^] # Re: Compatibilité avec df
Posté par THE_ALF_ . Évalué à 8.
Le problème est que cela veut dire que du fait de ces choix, on ne peut pas utiliser dfc comme un remplacement de df. En particulier cela risquerait de casser tout scripts ou autre programme faisant appel à df, ou d'empêcher l'utilisation de dfc comme une "alternatives" à df. Et ça casse les habitudes (honnêtement, la première commande que j'ai tapée pour voir ce que l'on pouvait faire à été "dfc --help"…)
Tu fais ce que tu veux, bien sur, c'est juste que ça me semble dommage de se couper d'une possibilité d'utilisation (i.e. utiliser dfc comme un ajout de couleur à df plutôt que comme une nouvelle commande similaire à df) pour vouloir d'autre options de configurations que celles l'outil standard.
[^] # Re: Compatibilité avec df
Posté par Jeanuel (site web personnel) . Évalué à 4.
Je me permet de dire que je suis 100% d'accord. dfc me parait une très bonne idée. Mais comme 99% des utilisateurs potentiel, j'ai pensé à un alias de df vers dfc.
Avec une similarité des options, dfc pourrait bien devenir un outil présent partout où se trouve déjà df. Dans le cas contraire, dfc restera certainement une belle démonstration technique.
[^] # Re: Compatibilité avec df
Posté par Rolinh (site web personnel) . Évalué à 3.
C'est un point de vue que je comprend. Cependant, il faut comprendre pourquoi ce n'est pas possible de mon point de vue: dfc est multiplateforme.
Le df(1) de FreeBSD n'est pas le même que le df(1) des coreutils par exemple. Les options ne sont pas les mêmes déjà rien que par le fait que les outils système des *BSD ne possèdent pas les options longues (qui, comme je l'ai déjà dit, sont une extension GNU). (manpage de df(1) de FreeBSD, manpage de df(1) des coreutils).
Dans ce contexte, je suis obligé de faire des choix. Mon point de vue est que les options longues sont une aberration (c'est mon avis, il est subjectif hein) et je ne les utilise donc pas. Donc je peux essayer d'être au plus proche des options des df(1) mais je ne pourrais jamais avoir exactement les mêmes. Une compatibilité à 100% avec les df(1) est simplement impossible.
En revanche, je ne conseillerais pas d'utiliser dfc(1) dans des scripts destinés à être partagés (peu importe pour les scripts perso) pour la simple et bonne raison que ce n'est pas un outil fournit de base avec le système, au contraire de df(1).
Je suis désolé si j'en déçois certain mais je ne pense pas que mon choix soit irrationnel.
Et puis taper "dfc" ne fait toujours qu'une lettre de plus que "df". ;)
[^] # Re: Compatibilité avec df
Posté par gouttegd . Évalué à 4.
Je ne trouve pas ça très convaincant comme explication. Les options longues sont une extension GNU, certes, mais elles sont aussi disponibles sous d’autres systèmes, notamment tous les BSD (enfin, au moins le Free, le Net et l’Open, ceux pour lesquels j’ai vérifié). Utiliser getopt_long ne condamne pas un programme à ne fonctionner que sous un système GNU, heureusement.
Ah, voilà donc la vraie raison. :) Là, je n’ai rien à redire, c’est ton choix.
[^] # Re: Compatibilité avec df
Posté par Rolinh (site web personnel) . Évalué à 4.
Oui, c'est vrai, getopt_long(3) est aussi disponible sous les systèmes *BSD. En revanche, les outils standards *BSD ne possèdent pas d'option longues. En utiliser pour dfc le rendrait incompatible avec les df(1) des *BSD au même titre que ne pas en utiliser rend dfc incompatible avec df(1) des coreutils.
C'est dans ce sens là que j'entendais que le fait que dfc(1) soit multiplateforme est un "problème", pas dans le sens "les options longues ne sont pas disponibles pour les systèmes *BSD" puisque ce n'est pas le cas. ;)
De toute façon, il y a un choix à faire et le mien est de ne pas utiliser les options longues (pour la raison que j'ai évoquée).
[^] # Re: Compatibilité avec df
Posté par gouttegd . Évalué à 2.
OK, j’avais compris ça de travers, autant pour moi.
[^] # Re: Compatibilité avec df
Posté par Jeanuel (site web personnel) . Évalué à -1.
C'est autorisé, mais c'est moche. Au temps pour toi.
[^] # Re: Compatibilité avec df
Posté par gouttegd . Évalué à 2.
Je le savais ! Je le savais que quelqu’un réagirait là-dessus, c’était inévitable !
Alors, pour ne pas m’étendre là-dessus plus que nécessaire : en l’absence d’une justification consensuelle et convaincante pour la graphie « au temps pour moi », j’utiliserai la graphie « Autant pour moi » si ça me chante. L’Académie française peut bien dire que « rien ne justifie » cette graphie, elle ne justifie pas davantage « Au temps pour moi » et, en constatant l’utilisation courante de « Autant… », elle ne tranche pas entre les deux formes.
Moi, je trouve que la pseudo-apostrophe droite, c’est très moche, mais je n’en fais pas la remarque à la moindre occasion.
[^] # Re: Compatibilité avec df
Posté par djano . Évalué à 2.
Salut,
Bravo pour ce logiciel qui améliore le bon vieux df(1) pour nous les humains :).
Non: utiliser les hypothétiques options longues de dfc dans des scripts rendrait les df(1) des *BSD incompatibles avec ces scripts, mais l'inverse n'est pas vrai. Si un logiciel ABC fournit X options, mais que le logiciel DEF en fournit X + Y, alors DEF est compatible avec ABC, ou dit autrement: il n'est pas incompatible.
Par exemple, df(1) des coreutils est compatible avec les df(1) des *BSD, mais les df(1) des *BSD ne sont pas compatibles avec df(1) des coreutils. Donc df(1) des coreutils n'est pas incompatible avec les df(1) des *BSD. Je ne sais pas si je suis clair.
La on est d'accord lorsque des scripts externes appellent les dites options longues.
De toute façon, tu n'aimes pas les options longues alors pas besoin de parler du reste puisque tu es le mainteneur. :)
Si ton but n'est pas de remplacer df(1), alors c'est ton choix (même si je trouve ça dommage :) ).
[^] # Re: Compatibilité avec df
Posté par Rolinh (site web personnel) . Évalué à 2.
Merci :)
Oui, tu as été clair. ;)
A vrai dire, je n'avais pas vraiment de but pour dfc(1) à la base. Je l'ai écrit parce que ça m'amusait puis, le trouvant pas trop mal, je l'ai partagé pour en faire profiter d'autres.
Maintenant, je suis toujours ouvert à la discussion même s'il est peu probable que j'inclue les options longues dans dfc(1).
# Je ne comprends pas.
Posté par detail_pratique . Évalué à 0.
Dans fon cul ? Ça veut dire quoi ?
# pydf
Posté par erdnaxeli (site web personnel) . Évalué à 4. Dernière modification le 01 avril 2012 à 15:41.
Il y aussi pydf. Il respecte les options de df, et ajoute un petit graphique (une barre du style [####…………………]). Comme je n'ai pas vu de screenshot de dfc je ne sais pas si ça fait la même chose.
Bon par contre il n'y a pas (à ma connaissance) d'options de filtrage ni d'affiche des options de montages.
[http://freecode.com/projects/pydf]
Il existe deux catégories de gens : ceux qui divisent les gens en deux catégories et les autres.
[^] # Re: pydf
Posté par Rolinh (site web personnel) . Évalué à 1.
Oui, cela fait grosso-modo la même chose. Tu peux trouver deux captures d'écran de dfc(1) sur la page principale du wiki.
[^] # Re: pydf
Posté par cdemoulins . Évalué à 0.
En terme de lisibilité, je trouve qu'utiliser des # et des . est plus lisible que des * et des -.
Mais bon ce n'est que mon opinion.
[^] # Re: pydf
Posté par Rolinh (site web personnel) . Évalué à 1.
Oui c'est vrai. Je viens de tester pour voir comment cela donnait et avec la couleur je trouve que c'est trop "flashy" avec les #.
J'ai testé avec le signe "=" est cela semble un bon compromis (plus lisible que les * mais pas autant flashy que les # ). Peut-être le bon choix?
image avec les tests
[^] # Re: pydf
Posté par Tony Flow . Évalué à 2.
Je trouve ça parfait les '='
(chouette on va avoir une version 2.5.0 dans la journée si on est sage ;p)
[^] # Re: pydf
Posté par Rolinh (site web personnel) . Évalué à 3.
Heu… Je ne pensais pas sortir une version tout de suite, sinon je vais encore me faire taper sur les doigts. :P
Enfin bon, j'ai corrigé plusieurs bugs relevés par des gens d'ici et ai porté dfc sous Mac OS (merci à un lecteur de linuxfr au passage). Ça serait peut-être dommage de faire patienter les utilisateurs de MacOS jusqu'à la version 3.0.0 qui ne sortira sûrement pas avant un bon bout de temps…
# Dans le même genre
Posté par laurentb (site web personnel) . Évalué à 5.
Il y a pydf. Je l'avais utilisé un temps, pour finalement revenir sur df ou di, mon favori. Peut-être parce qu'il était lent à se lancer.
Là je viens de tester dfc, c'est instantané et l'affichage est beaucoup plus clair !
J'ai fait un ebuild Gentoo pour les intéressés :
layman -a laurentb && emerge dfc.Sinon, il y a un truc que fait di que je trouve pas mal, il trie les points de montage par nom, c'est utile quand on en a beaucoup (et, hasard des choses, ça met les FS « réels » au début).
[^] # Re: Dans le même genre
Posté par duf . Évalué à 2.
Merci c'est bien pratique que tu aies fait cet ebuild ça m'a permis de le tester super rapidement ;-) La seule action que j'ai du faire c'est de toucher au keyword vu que je suis en stable, trop dur :-p
Pour dfc sinon, j'aime bien la sortie que rend :
dfc -wT# Git, bug
Posté par rogo . Évalué à 1.
J'ai eu du mal à trouver l'URL pour cloner le dépôt Git. Dans le wiki, on trouve un lien vers la FAQ, et la 6e question donne le lien. C'est beaucoup trop caché à mon goût — j'avais cherché ce lien pendant 2 minutes sans trouver avant de tomber dessus par hasard.
Sinon, un petit bug :
dfc -t -udevne masque pas les montages de type "udev". Ça marche avec "tmpfs" et "rootfs", même combinés en "-tmpfs,rootfs". Debian testing amd64.Je sais que j'aurais dû créer un ticket dans la forge, mais j'ai la flemme de me créer un compte à usage unique.
[^] # Re: Git, bug
Posté par rogo . Évalué à 2.
Autre bug, plus gênant : dfc tronque les chemins de montage.
[^] # Re: Git, bug
Posté par rogo . Évalué à 2.
Un dernier bug pour la route : les colonnes se recouvrent parfois.
[^] # Re: Git, bug
Posté par Rolinh (site web personnel) . Évalué à 3.
C'est vrai que l'URL pour le dépôt git est un peu cachée. Je trouverais logique qu'elle soit affichée quelque part lorsque l'on clique sur "Repository" mais il me semble que Chiliproject ne le permet pas (ou en tout cas, je n'ai pas trouvé l'option).
Pour ce qui est de
udev, je ne suis pas certain qu'il s'agisse d'un bug. Le filtrage se fait sur le type de système de fichiers.Exemple (
dfc -T):Et donc (
dfc -T -t -devtmpfs):Pour l'histoire de la troncation, cela devait être une feature que j'ai implémenté sur demande d'une personne. Je pensais que l'on ne perdait pas d'information pertinente mais il se trouve que cela semble être le cas.
Enfin, le recouvrement des colonnes est un véritable bug dont il faut que je m'occupe.
Merci d'avoir rapporté ces problèmes.
# conf
Posté par chmanu . Évalué à 1.
Sympa ce petit dev.
Est-il envisagé un fichier de conf (~/.dfc) pour gérer les couleurs, la valeur des seuils ?
[^] # Re: conf
Posté par Rolinh (site web personnel) . Évalué à 2.
Pourquoi pas?
Allez, je mets dans la roadmap pour la version 3.0.0 ;)
[^] # Re: conf
Posté par Anonyme . Évalué à 4.
Je corrige le commentaire du dessus :
${XDG_CONFIG_HOME}/dfc/ou.config/dfc/dans le cas ou${XDG_CONFIG_HOME}n’existe pas.Cf. http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
# 2.5.0: Support de Mac OS et plus...
Posté par Rolinh (site web personnel) . Évalué à 2.
N'en déplaise à certains, j'ai estimé profitable à tout le monde la sortie d'une nouvelle version de dfc(1). Elle apporte pas mal de choses dont le support de Mac OS, le support de l'option -o pour FreeBSD, une nouvelle option, un petit changement visuel et la correction des bugs relevé par des gens ici en plus de plusieurs autres ainsi qu'une réorganisation de code majeure.
Pour les détails, lire l'annonce (en).
[^] # Re: 2.5.0: Support de Mac OS et plus...
Posté par djano . Évalué à 2. Dernière modification le 04 avril 2012 à 08:35.
C'est la version 2.5.0 .
Il y a un petit souci dans l'annonce:
There is one new option: -W prevents the names from being truncated.
Le reste de l'annonce est tout bon.
Bravo pour ta réactivité!
[^] # Re: 2.5.0: Support de Mac OS et plus...
Posté par Rolinh (site web personnel) . Évalué à 1.
Oui, effectivement (j'ai finit tard hier soir…).
Merci.
# Dispo dans Mageia Cauldron
Posté par littlebreizhman . Évalué à 2.
Et donc dans la future Mageia 2
http://svnweb.mageia.org/packages?view=revision&revision=227898 en version 2.4.0.
Merci à celui/celle qui l'a soumis/ajouté dans les dépôts…
# Feature request
Posté par calandoa . Évalué à 3.
Ajouter un flag pour trier les FS. Par exemple par ordre alphabétique, ou afficher uniquement les /dev/sd* ou dev/hd* car généralement c'est juste eux qui nous intéressent. Oui, on peut le faire avec "-t", sort, grep ou un super script perl de 1 ligne (de 32423 caractères), mais un flag, c'est plus simple.
[^] # Re: Feature request
Posté par Rolinh (site web personnel) . Évalué à 2.
C'est quelque chose qui peut se faire, effectivement. J'avais déjà eu une demande par rapport à une feature de tri mais ne l'ai pas encore traitée, la jugeant moins importante que le reste.
Par contre, je peux ajouter une nouvelle option pour le tri selon le FS. C'est une excellente idée.
J'ajoute cela à la liste de features prévues pour la version 3.0.0.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.