Bapt a écrit 772 commentaires

Un lien vers la doc 4.3.5 en pdf : http://baptux.free.fr/zsh.pdf et vers celle en html pour le module curses : http://baptux.free.fr/zsh/zsh_22.html#SEC171

Voici un exemple de code :

curses_test () {
win=toto
zmodload zsh/curses
zcurses init
zcurses addwin $win 10 20 1 1
zcurses border $win
zcurses move $win 4 2
zcurses string $win "HelloWorld !!"
zcurses refresh $win
sleep 5
zcurses delwin $win
zcurses end
}

curses_test

La doc zsh est très bien foutu, complète et disponible sous forme pdf, html, man ou GNU info.
Le site n'est pas encore à jour concernant les dernières versions de la doc. Mais les distributions distribuent la doc à jours avec zsh (c'est au moins le cas avec gentoo - le use doc -)

Sinon le problème que tu évoques est identique quand tu code pure bash ou pure ksh, tu ne peux pas l'utiliser sur d'autres shells, (sauf zsh grace aux fonctions emulate)

Si tu veux que ton code marche partout, il suffit de faire du code POSIX.

Bravo, c'est beau, c'est propre et ça donne bien envie de l'utiliser, malheureusement, pourquoi bongo fournit il son bongosmtp et bongoimap ? j'ai un beau postfix/dovecot qui marche d'enfer. Ce serait certainement plus simple et moins lourd (pour les devs) de s'appuyer sur de l'existant : proto SMTP/IMAP plutôt que de recoder et maintenir ces serveurs.

Y a certainement une bonne raison derrière ça, mais j'aimerai bien qu'on me l'explique.

Bref ça semble du bon boulot, mais je ne pourrai pas l'utiliser dommage...

SVP dites moi qu'il y a une astuces pas trop gruiik pour utiliser dovecot/postfix avec bongo!!!

Non c'est le port qui est repris de 0, c'est pas du reverse engineering, c'est bien le même Dtrace qui sera disponible (et qui d'ailleurs est déjà disponible sous forme de patch pour 8-CURRENT).

Concernant les brevets je ne sais pas ce qu'il en est, mais SUN, mais le cas de ZFS comme Dtrace a plutôt été ouvert au port sur FreeBSD, est même plutôt colaboratif sur le plan technique.

Sauf que le port de Dtrace sous FreeBSD a été repris de 0 par la même personne que le premier port (sponsorisé par cisco) et ce coup ci, il devrait être intégrable dans FreeBSD.

cf http://dtrace.what-creek.com/ et
http://marc.info/?l=freebsd-current&m=120113328805223&am(...)

Merci, pour les remarques.
je comptais mettre les liens à la fin.

ainsi, je vais de la même manière ajouter un lien et la section de manpage concernée à par chaque driver/outil lors de la mise en forme définitive.

Je sens qu'il va me plaire celui-ci, merci pour ton boulot, et aux autres développeurs.

Je m'en vais tester de suite. Ca fait plaisir de voir un projet jeune bien documenté, En plus ça tombe bien, juste au moment ou je cherche un WM a cheval entre de l'openbox et wmii.

Non car c'est mon programme C d'origine qui va faire un dlopen sur ma lib pondue par vala.

l'intérêt est par exemple de pouvoir créer facilement un plugin pour un programme C qui ne supporte pas de binding pour son interface de plugin par exemple. Le tout en utilisant un langage haut niveau.

FreeBSD peut disposer de sa partition root sous ZFS : http://wiki.freebsd.org/ZFSOnRoot

Oui mais une distro intègre aussi des softs pas propres niveau code, donc gérer plusieurs archi reste quelque chose de complexe dans le cadre d'une distrib.

Il y a une différence entre faire une appli non multiplateforme, qui a part spécificité si elle est codée proprement sera relativement facile à porter, et faire une distro multi-archi.

Je l'ai testé sous archlinux donc version (3.0.1.6) avec icedtea 1.4 ça fonctionnait déjà parfaitement.

D'ailleurs je tiens a ne pas remercier les contributeurs icedtea d'avoir modifier le configure icedtea pour récupérer les sources openjdk via mercurial et un plugin de celui-ci (forest) uniquement disponible via mercurial lui-même, pas terrible pour l'automatisation d'un builder (tinderbox). avant openjdk était rapatrier depuis une archive sur le web c'était quand même mieux.

Sinon je tiens quand même à les remerciers énormément car à part un patch pour virer le -Werror, ça build tout seul :)

Aussi dispo pour archlinux via AUR...

elinks \0/

enfin je ne sais pas, par exemple des soft qui sont complement réecrit chez BSD parceque la licence (GPL) originale ne leur plais pas.

C'est rarement le cas, la plupart du temps c'est une autre motivation qui pousse à la réécriture en licence BSD, par exemple, un soft non maintenu opencvs, des programmes mal adaptés aux besoins des BSD par exemple le projet bintools en ce moment, car binutils ne leur convient pas. une meilleur architecture de programmes qui pourrait bénéficier à beaucoup d'autres et ainsi facilité la maintenance et/ou les performances, par exemple libarchive (bsdtar, bsdcpio, les futurs pkg_tools de freebsd)

Enfin il y a bien des cas comme tu les décrit, mais c'est plus une question de non contamination (ils veulent conserver le code de l'OS sous licence BSD) par exemple readline intéressant beaucoup utiliser mais sous licence GPL donc si les softs BSD sont "linkés" sur cette lib ils deviennent GPL donc NetBSD pond libedit.

Bref, la recode pour cause de licence n'est presque jamais la raison première, même si ils préfèrent avoir le moins possible de GPL dans le userland.

Bah tu dois très certainement mal utiliser zsh ou l'utiliser à la bash.

Car zsh permet autrement plus de choses que bash notamment en ce qui concerne la programmation. Une bonne lecture (longue) de http://zsh.dotsrc.org/Doc/ pourra te donner un bon apperçu.

La lenteur du shell est relative, comme indiqué plus bas on passe souvent par des appels à des programmes externes (grep awk sed cat etc.) là où ce n'est absolument pas nécessaire en tout en zsh pour ce que je connais. Pour convertir souvent des script bash/ksh en zsh je peux te garantir que quand tu vires which/grep et consors tu as souvent un gain de performances important.

d'ailleurs dans la foulée : dans la version de dev de zsh, un nouveau module est en train de faire son apparition : zcurses => exit dialog \0/.

Le prochain freebsd ne sortira pas en 2009, il devrait y avoir des version 7.X et 6.X entre temps, donc aussi des amélioration et du peaufinage. En 2008 la prochaine version majeure du kernel et donc de l'OS devrait sortir (les cycles de développement de FreeBSD n'ont rien a voir avec celui de linux)

secundo il ne s'agit en aucun cas d'une communication officielle, d'ailleurs le bench tout comme le pdf ne disent pas linux c'est de la merde il sont trop naze, ils ont 15% d'écart avec nous, ils disent "enfin sched_ule" est concurrentiel, et FreeBSD est de retour parmi les OS performant sur du matos moderne.

Donc contrairement à ce que dit l'auteur du journal, il ne s'agit pas d'un défi lancé aux devs de linux, pour preuves, l'auteur du boulot sur shed_ule et des bench a donné un maximum d'information aux développeurs linux pour qu'ils puissent corriger les bugs qu'il avait découvert, il a même accepter de refaire ces benchs en prenant en compte les modifications/optimisation qui lui ont été recommandées par les devs linux, il s'agit simplement d'essayer de se positionner par rapport à un OS comparable.

Pour finir sortir une version tous les 2 ou 3 mois ne signifie pas en aucun cas progresser plus vite, cela signifie juste faire des release plus fréquentes. Le foin c'est vous (ceux qui sentent linux attaqué par le rapport et les bench) et l'auteur du journal qui le font.

http://marc.info/?l=freebsd-stable&m=119335156500960&(...)

Apparemment il y a eu un loupé dans la génération des isos, ceux de la 7.0-BETA1 correspondent en fait à la nouvelle branche current soit 8 des nouvelles isos estampillées 7.0-BETA1.5 ont été générées et sont disponibles.

Voici aussi le bulletin trimestriel du développement autour de FreeBSD : http://www.freebsd.org/news/newsflash.html#event20071010:01

Je voulais en faire une news, comme pour les précédents, mais je n'en ai pas du tout le temps.

Je n'utilise pas gnome, et je n'ai aucun programme qui utilise gconf, il faut dire que je n'utilise pas beaucoup de programmes graphiques.

Pour mpd j'utilise http://emphasis.tuxfamily.org/ (mais je ne suis pas sous e17), mais il n'avance pas beaucoup, ario répond à mon besoin, mais ça m'embête un peu la dépendance gconf (au pire je pourrais quand même vivre avec :)).

Félicitation Ario est très bien et me plait beaucoup.

Apparemment tu souhaite être "léger", et supprimer certaines dépendance "inutiles" (gnome-vfs eel) comptes tu pousser un peu plus et supprimer la dépendance gconf (j'aimerai bien :)) ou non ?

Je ne connais pas bien ubuntu, mais tu es obligé d'attendre fluxbuntu ?

Tu ne peux pas l'installer en version minimaliste et faire un simple apt-get install fluxbox ? Ca te permettrait de tester fluxbox maintenant non ?

Freebsd ne propose pas la possibilité de mélanger plusieurs versions d'une bibliothèque partagée

si ils proposent une solution, lors d'un mise à jour des packages, les bibliothèques partagées qui changent de numéro shmajor lors de la mise à jour, sont conservées dans /usr/local/lib/pkg pour conserver la compatibilité avec les autres applications installées. On dispose donc de la nouvelle lib, et l'ancienne est conservée pour pouvoir faire une transition en douceur.

Arrête de raconter n'importe quoi :
OpenBSD dispose toutes les versions *récente* de GCC au travers des ports : http://ports.openbsd.nu/lang/gcc jette un oeil et tu verras, il y a même des ports pour les version 4.X et même celle en dev (4.3), donc tu as bien des mecs qui se prennent la tête a intégrer gcc dans OpenBSD y compris dans les versions récentes. En plus c'est la même personne qui les maintient, mais comme tu le dis, le mec ne doit pas savoir il en son resté à la version 3.3...

De plus si OpenBSD en est resté à la version 3.3 pour la compilation des sources officielles, et 2.95 pour certaines archi, c'est peut être bien parce que gcc n'est peut être pas si facile que ça a intégrés : comme dit dans ce que tu quotes : certaines architectures non supportés, du GNUisme, des buts différents de ceux des devs d'OpenBSD. Bah dans ces cas là tu changes dès que tu le peux pour un produit qui leur correspond mieux.
Ensuite pour les postes de baves sur GCC, si tu lis les premiers posts (je ne parles de trollfr, mais bel et bien des annonces officielles) qui parlent de l'import de pcc dans gcc ça ne bave pas sur GCC, mais ça dit juste que PCC pourrait mieux correspondre à leur besoin, par la suite ça bave car rien que le fait de penser proposer un compilateur alternatif pour leurs sources en C, entrainent une levé de bouclier de gens comme toi, et comme des gens prêt à troller et à baver il y en a *plein* dans tous les camps, (Théo est très souvent en première ligne pour ça, mais Linus n'est jamais bien loin non plus.) ça crache dans tous les sens.

Toi par exemple dès ton premier post du bave sérieusement sur les BSD : http://linuxfr.org/~inico/25304.html#867189

Toi tu n'as vraiment jamais essayé les FreeBSD pour pouvoir affirmer de telles choses, toutes les questions que tu poses trouvent leur réponses dans la documentation fournie par les différents projets : le handbook pour le cas de FreeBSD, va le lire (attention c'est long, tout y est documenté :)) et tu verras.

Les paquets binaires gèrent parfaitement les dépendances, les dépendances sources et binaires peuvent allègrement être mélangées puisse que les paquet sont produit depuis l'arbre des sources (ports).

Autant de réponses que freeBSD n'apporte pas. Ce manque d'une politique *clairement* définie montre le peu d'importance qu'elle accorde aux paquets binaires.

1/ les réponses sont apportées va lire les docs.

2/ la politique est clairement établie, va voir les docs aussi à ce propos, les paquets binaires sont au contraire de ce que tu affirmes. très importants.

Beaucoup d'âneries et d'affirmation sans fondement dans tes posts sur FreeBSD, tu ne travaillerais pas chez 01 ?

Ce que je dit là est tout autant valable pour NetBSD avec son pkgsrc, et OpenBSD avec ses ports.