Bapt a écrit 772 commentaires

bash-completion est la completion dite 'intelligente',

on est bien d'accord, le zsh 3.0.X dont je parle a bien la completion "intelligente", par exemple dans le liste ci dessus :
- hostname completion (faut aller les cherchés),
- option completion (pas besoin de dessin),
- anything else you can think of (donc intelligente et programmable)

Mon but depuis le début est justement de montré que l'utilisation de sed grep awk etc. ralenti les scripts et que zsh peut dans le cas de programmation complexe (loin de l'exemple que je montre) permettre de faire de la programmation shell avec des meilleurs performances que la plupart des autres car permet de se passer de ses outils.

Pour le montrer j'ai pris un truc echo avec un rechercher remplacer simple (qui existe aussi bien en bash que en zsh pour le coup mais pas en bourne shell). D'ailleur dans mon post précédent je dis bien que dash/ash sont plus rapide que zsh en leur faisant executer le même script (avec sed). Ils sont même certainement mieux adaptés dans beaucoup de cas.

Mais dash/ash ont des limitation d'un point de vue programmation comparés à zsh, idem pour bash. Mais ils sont plus rapide (dash/ash) ils n'ont pas le même but. Alors que bash et zsh oui.

Mon exemple démontre ce qu'il veut démontrer, à savoir utiliser des applis externes est coûteux.

le ne connais pas l'historique exacte de ZSH (ni ou le trouver), mais la slackware 3.3 de juillet 1997 fourni zsh-3.0.3 qui dispose déjà de la completion avancée avec menu interactif pour les options de completions, et plein d'autres fonctions :
- command name completion
- filename and path completion
- hostname completion
- key binding completion
- option completion
- variable name completion
- user-specified keyword completion
- anything else you can think of

selon le release note la 2.5 comportait déjà des améliorations concernant la completion. je ne sais pas de quand date la version 2.5, mais elle est certainement bien plus vieille que ça et elle améliorait la completion.

Je commence peut être à me faire vieux, mais l'apparition de bash-completion me semblait plus jeune que ça. En même temps, en 2000 c'était pas très utilisable. Ce que je sais c'est que mon zsh de 1998 (date ou je l'ai découvert) faisait déjà la completion à merveille :).

Et puis vu que dash (shell minimaliste) est souvent plus rapide que bash, j'ai de gros doute sur les perfs de zsh.

Ce que tu dis est vrai pour des scripts posix uniquement donc faisant appel à des commandes externes pour tout ce qui n'est pas gérer par le bourne shell (grep, awk, sed, etc.)

dash est l'implémentation de ash. sur mon poste freebsd /bin/sh correspond à ash donc la même chose que dash.

si je fait le même test que j'ai fait au dessus.

version bourne shell de extern.zsh ca donne :

let $(( n = 0 ))
while [ $n -ne 100 ] ;do
TOTO=truc
echo $TOTO | sed 's/ruc/oto/'
let $(( n = n + 1 ))
done


sh extern.sh > /dev/null 0,21s user 0,53s system 99% cpu 0,746 total

alors que natif.zsh donne :
zsh natif.zsh > /dev/null 0,01s user 0,03s system 96% cpu 0,038 total

Bien sûr ce n'est pas un benchmark, mais ça donne une idée, l'intérêt de dash et ash c'est de respecter les strictosensus le bourne shell, et donc de fournir une implémentation légère et très peu gourmande en mémoire. ce qui dans des contraintes de petite configuration peu s'avérer intéressant.

biensûr zsh est compatible bourne shell, et sur du bourne shell pur il est plus lent et gourmant que dash ou ash :
zsh estern.sh > /dev/null 0,26s user 0,71s system 99% cpu 0,976 total

voila comme souvent tout dépend du besoin et des contraintes de destinations.

Beaucoup de script shell gagnerait à utiliser du zsh avancé, mais ce n'est pas la solution unique

PS:
test sur FreeBSD 6.2-RELEASE sur pentium III IGhz avec 512 Mo de RAM. La même chose sur une machine genre p133 16Mo de RAM devrait normalement plus tourner en faveur de dash/ash (ce serait intéressant de faire le test)

A mon avis ca vient de ton utilisation, et peut être un peu de la conf (je ne me souviens pas la dernière fois que j'ai utiliser la conf par défaut des OS que j'utilise.)

Maintenant qu'est ce que tu entends pas gros et lent.

un appel a une commande externe est la plus part du temps beaucoup plus couteux en temps que la même chose faite nativement. Surtout quand c'est répété.

Par exemple :
extern.sh

n=0
while [ $n -ne 100 ] ;do
TOTO=truc
echo $TOTO | sed 's/ruc/oto/'
(( n = n + 1 ))
done

ou
natif.sh

n=0
while [ $n -ne 100 ] ;do
TOTO=truc
echo ${TOTO/ruc/oto}
(( n = n + 1 ))
done

donne chez moi :
zsh extern.zsh > /dev/null 0,28s user 0,69s system 99% cpu 0,977 total
zsh natif.zsh > /dev/null 0,01s user 0,03s system 96% cpu 0,038 total

La différence est quand même flagrante, pourtant quand je la 10 occurrence de la boucle au lieu de 100 la différence ne se voit pratiquement pas.

(Note que mon exemple doit aussi fonctionner sous bash.)

la question n'attendait pas réponse :)

Ce que j'ai toujours eu du mal à comprendre (d'un point de vue technique), mais qui peut certainement s'expliquer par trois lettre : GNU
La majeure partie des distrib se disent GNU/Linux donc Linux + utilitaires GNU donc bash.

Moi je n'installer bash sur mes machines sauf à cause de git (quel est l'idiot qui a décider de faire du bash en lieu et place du bon vieux bourne shell pour les scripts git...)

au fait zsh est déjà dans quasiment toutes les distros et os libres.

La dépêche se sera plutôt pour la version stable officielle (4.4.0 :))

Concernant la licence, elle est courte, le mieux c'est de la lire :

The Z Shell is copyright (c) 1992-2007 Paul Falstad, Richard Coleman,
Zoltán Hidvégi, Andrew Main, Peter Stephenson, Sven Wischnowsky, and
others. All rights reserved. Individual authors, whether or not
specifically named, retain copyright in all changes; in what follows, they
are referred to as `the Zsh Development Group'. This is for convenience
only and this body has no legal status. The Z shell is distributed under
the following licence; any provisions made in individual files take
precedence.

Permission is hereby granted, without written agreement and without
licence or royalty fees, to use, copy, modify, and distribute this
software and to distribute modified versions of this software for any
purpose, provided that the above copyright notice and the following
two paragraphs appear in all copies of this software.

In no event shall the Zsh Development Group be liable to any party for
direct, indirect, special, incidental, or consequential damages arising out
of the use of this software and its documentation, even if the Zsh
Development Group have been advised of the possibility of such damage.

The Zsh Development Group specifically disclaim any warranties, including,
but not limited to, the implied warranties of merchantability and fitness
for a particular purpose. The software provided hereunder is on an "as is"
basis, and the Zsh Development Group have no obligation to provide
maintenance, support, updates, enhancements, or modifications.

non zsh a la completion depuis longtemps, bash depuis peu, mais comme c'est bash, gnu toussa... il y a forcément plus de mecs dessus donc rapidement il y a des fonctions de completions qui existent sous bash-completion qui ne sont pas encore dans zsh, donc zsh à décider de faire une fonction bashcomp qui permet d'utiliser les fonction de completions bash en plus de celle de zsh.

Bon pas eu le temps de beaucoup jouer avec, mais il s'installe et fonctionne, c'est déjà bien.


voila merci pour tout, enfin un "vrai" et bon client mail pour le nokia 770.

Cool, j'avais essayer le port de sylpheed mais il n'était pas terrible (interface graphique très peu adaptée) je vais dès ce soir essayer claws sur mon n770 :).

Merci pour le boulot

Si c'est pour répondre sur ce ton, y a pas de besoin ... Franchement, faut arrêter de se prendre autant au sérieux.

En même temps, je réponds volontairement sur le même ton que celui que tu emploies (du moins tel que je l'ai perçu).

En lisant ton post c'est comme si il était inadmissible que les binaires fourni ne fonctionne pas sur ta distrib en version stable.

J'aurai été développeur du jeu, je pense que j'aurai mal pris ton post, il y a des manière plus sympathique de dire "chez moi ça ne marche pas avez vous une solution", plutôt que :

Je ne vais quand même pas passer en instable pour tester un jeux ?"

Tu n'as qu'à utiliser un OS à jour (moderne quoi) ou alors tu ne te plains pas, tu prends tes petits paquets devel, ton gcc, tu télécharges les sources, tu compiles.
Si ça marche tu es content (tu peux même faire un petit paquet pour tes petits camarades histoire que d'autres râleurs puissent en profiter) si ça compile pas, rapport de bug.

voila.

Il faudra vraiment m'expliquer ce qui sert encore dans les win32codecs, les seuls choses que tu y trouves et qui ne sont pas dans ffmpeg ou codecs tierces libres, c'est les dernier real (qui utilisent encore ce format, c'est devenu rarissime) La seule chose que je n'arrive pas à lire chez moi c'est donc le RV10, et ça a du m'arriver une fois d'en avoir un sous la main.

En ce qui concerne Reactos, j'ai fait exprès de le citer car je parlais de :

améliorer les solutions alternatives que 2 ou 3 clampins voudront éventuellement essayer de pondre, sous prétexte que "non, moi je m'en fous je veux que ça marche, j'utiliserai ton truc libre que si il est mieux, plus simple et marche à 100% (éventuellement je te dirais merci, mais c'est pas sûr)

un petit coup de main pour arriver à le rendre fonctionnel est toujours le bienvenue, si tu as besoin/aime bien Windows mais que tu veux du libre, teste Reactos de temps en temps et renvoie les bugs rencontrés pour ton utilisation, je suis sûr qu'il seront content d'avoir ce genre de retour.

Maintenant comme je le disais,

c'est votre droit, je m'en fous complètement, mais ne venez pas jouer les hypocrites en faisant les libristes convaincus,

je n'attendais pas de réponse dans gens pour ce justifier : oui mais j'ai que ces deux là..., c'est pas bien grave, pour le reste, je suis un bon libriste , ...

Un blob c'est par exemple la grosse interface binaire fourni par intel qui tourne en root, pour gérer le wifi.

http://en.wikipedia.org/wiki/Binary_blob

Après il faut utiliser les bons termes.

Pour pouvoir se battre contre ça, et amener la "liberté", il faut se battre sur leur terrain. Commencer par un BLOB plus efficace au début, diffuser Linux, puis virer le BLOB. Commencer sans le BLOB me parait moins efficace

Mais bien sûr tu connais le temporaire définitif ? c'est quand dans ta boîte on te dit tiens fait une rustine en attendant que l'on prenne le temps de corriger le réel problème. 10 ans après ta rustine elle est toujours là.

Les BLOB si on ne se bat pas tout de suite contre, ils resteront définitivement ou presque, il n'y aura personne pour tester et aider à améliorer les solutions alternatives que 2 ou 3 clampins voudront éventuellement essayer de pondre, sous prétexte que "non, moi je m'en fous je veux que ça marche, j'utiliserai ton truc libre que si il est mieux, plus simple et marche à 100% (éventuellement je te dirais merci, mais c'est pas sûr). Il utiliseront mon bon gros BLOB ou driver binaire.

Tu ne me crois pas regarde le driver nvidia, si nouveau est apparu c'est uniquement parce que Les initiateurs du projet avait besoin de faire des manip impossible avec le driver binaire nvidia.

Regarde la carte intel Wifi (j'ai plus la ref exacte) ils ont fait à la va vite un bon gros blob, et uniquement parce que ça gueulait trop ils l'ont viré (si on avait laissé faire on aurait toujours du blob)

Combien ici utilise le plugin flash au lieu d'utiliser/tester/faire des retours aux développeurs de GNASH ou swfdec (archi non x86 ou x86_64 pas besoin de répondre, vous n'avez pas le choix).

Combien utilise acroread au lieu de evince/epdfview/kpdf/... parceque acroread à la fonctionnalité de la mort qui sert une fois tous les 6 mois.

Combien utilisent vmware ?
Combien utilisent nsdiwrapper ?
Combien utilisent Opéra ?
Combien utilisent Windows ou Mac ou autres ?

c'est votre droit, je m'en fous complètement, mais ne venez pas jouer les hypocrites en faisant les libristes convaincus,
"ouais dès qu'il y a une solution, j'en ferai la promotion et serait le premier à l'utiliser" et puis après "Ouais c'est vrai on a maintenant qemu/virtualbox, mais vmware, il clignote de partout, et moi j'aime bien quand ça clignote".
Ou "Oui swfdec lit maintenant les youtubes et fait même des trucs que adobe flash ne fait pas, mais il a pris une fois 100% de CPU donc il est nul" (elle est ou la remontée de bug ?)

Pour tout ce que j'ai cité il y a des solutions pures libres qui ne demande qu'à s'améliorer et pour ça, elles ont besoins de d'utilisateurs, de développeurs, de traducteurs, de retour de bug pour s'améliorer.

Vérifier si son matos dispose d'un driver libre c'est pas très compliqué, utiliser les logiciels libre en lieu et place de logiciel proprio c'est pas très compliqué. Et c'est un peu de reconnaissance envers les devs qui se cassent le cul gratuitement pour ton plaisir :
Opera -> Konqueror, firefox,...
vmware -> qemu, virtualbox, xen, ...
flash : gnash, swfdec
Windows, Mac : Reactos, Linux, *BSD, etc.
etc.

Cette question est posée à chaque news FreeBSD, le mieux c'est d'essayer et tu verras.

sinon pour les réponses que j'ai déjà pu apporter par le passé : http://linuxfr.org/2007/02/12/22058.html#803928
ou
http://linuxfr.org/2006/08/24/21242.html#746945

http://marc.info/?l=freebsd-current&m=117589563130307&am(...)

Ca vient de tomber sur la ml, ça donne une bonne idée de ce que ZFS peut permettre :)

1/ On ne crie pas au loup avant de l'avoir vue, le mec en question est peut être super bon, et aurait pondu un driver BSD pure, ne reprenant rien du driver GPL, même si tout le monde sait que c'est très difficile ce n'est pas impossible.

2/ Il codait peut être directement depuis les specs, et se servait du driver GPL pour combler ce qu'il n'avait pas encore coder.

Qu'est ce qu'on en sait ? rien du tout !!

C'est quand même dingue de crier au loup systématiquement pour pas grand chose.

Est dans les habitudes d'OpenBSD de violer les licences ? ... non
Est une habitude d'OpenBSD de faire salement leur développement ? ... non

Donc avant fr lancer un flamewar publique, il aurait fallu attendre de voir ce qu'ils auraient fait, c'est OpenBSD c'est pas comme si c'était des mecs qui avait l'habitude de violer les licences à leur profit.

Ca ne coutait rien de prevenir le dev en privé qu'il avait fait une erreur en utilisant un CVS publique, et il n'y aurait pas eu de problèmes.

Comme il est dit dans le thread, le driver était en réécriture complète en BSD, mais le dev voulant avoir des résultats rapidement (c'est mieux pour la motivation), prenait des morceaux de code du driver GPL pour les parties qu'il n'avait pas encore recodé.
Donc au final le driver aurait été en BSD tout propre sans violation de GPL. (fait confiance à OpenBSD pour ça (cf iwi par exemple)).

La seule erreur du dev c'est d'avoir eu le malheur de committer sur un CVS publique.

Bref beaucoup de foin pour pas grand chose.

Et bien ceux qui pense ça n'utilisent pas zfs et continue de fonctionner avec leur LVM+FS+... personne ne viendra les embêter

Ceux qui veulent du tout en un prennent ZFS, personne ne viendra les embêter non plus.

Ou ceux qui veulent un FS+LVM qui soit partageable entre plusieurs OS prennent ZFS, pour le moment les OS qui peuvent partager : solaris 10, opensolaris, freebsd 7, macos 10.5.

Bientôt Linux avec fuse.

Voila pas troll, tout le monde il est beau, tout le monde il est gentil.

SystemRescueCd est créée à partir de gentoo, donc rien ne t'empêche de refaire la même chose (tu dois même pouvoir trouver sur le site de system rescue CD de quoi refaire le CD à la mano) qui boot sur PXE.

La doc pour installer une gentoo par PXE est ici : http://www.gentoo.org/doc/en/altinstall.xml

A toi de l'adapter :)

Oui alfresco est parfaitement utilisable dans un petite structure (je ne vois pas ce qui gênerai) une fois installé, qu'il y ait 10 ou 100 ou 1000 personnes qui travaille avec ça ne change rien (sauf la charge du serveur bien sûr :))

Ouais ou ne pas le faire en local et ouvrir le document directement depuis le partage CIFS, WEBDAV, autres et travailler dessus comme si on était en local. Dès l'enregistrement, la GED se fait de manière transparente.