Bapt a écrit 772 commentaires

bah zsh c'est un shell, qui offre des fonctionnalités de programation très avancées donc on a fait un répertoire de centralisation des fonctions zsh, et contrairement à d'autres shell, on a pas besoin dans la plupart des cas de faire appel à des programmes externes : grep, cat, etc.

si tu pouvais nous ouvrir un bug en précisant la version zsh et tout ce qui va avec ça nous aidera bien à corriger ça, merci.

bon alors
1/ zen n'est pas gestionnaire de package
2/ on fait ça pour le fun, et pour montrer la puissance de zsh en tant que language de scripts
3/ on fait ça pour éviter aux gens de réinventer la roues, et notre echo système c'est uniquement zsh et non pas tout un os.

Ensuite pour la perte de temps ça pourrait bien être le cas si j'avais voulu passer du temps sur deb rpm ou autres, mais non je ne l'ai pas fait donc je ne fais perdre de temps à personne, par contre le mec qui veut se faire des scripts en 2s dans sur un coin de table sera content de trouver un point centrale ou disposer de fonctions déjà existante et fonctionnelles.

Maintenant si une distrib veut packager le contenu de zen tant mieux même si je ne vois pas trop l'intérêt quel pourrait y trouver.

il n'y a pas de url_encode dans zen, tu dois surement avoir des trucs perso qui conflict.

tien autre chose c'est libre ?
Où sont :
- la licence : rien trouvé sur le site
- les sources : rien trouvé sur le site
- le bug tracker : rien trouvé sur le site

Au minimum les sources et la licence ça serait pas mal

oups désolé pour le gras j'ai du oublié la balise fermante je voulais du gras juste pour BLAM :(

Je lis le descriptif tout de suite je me dis hum intéressant faut voir je vais sur le site, et comme il y a peu de doc pour mieux se rendre compte du truc du coup je vais pour regarder les captures d'écran et BAM page blanche avec la petite barre vous n'avez pas les bon plugins.

Nan mais flash pour des captures d'écran, du coup il ne m'est pas possible de voir ça. Pour des vidéos je peux comprendre bien que je préfère la bonne vieille balise object et mon plugin qui va bien mais là franchement merde quoi c'est juste des images.

Je ne suis pas complètement obtu, je téléchargerais quand même, mais faites un effort SVP

> La CDDL spécifiquement fait pour être incompatible avec la GPL (et donc Linux) tu en fais quoi ?
Nan mais arrête ton FUD, dans ces cas là attaque toutes les licences libres qui sont incompatibles avec la GPL de la même manière.

Toutes les dérivées de la MPL sont donc contre Linux, hein !!!

> On ne peut pas forcément dire que Sun est hostile envers Linux, mais quel manque d'entrain.
Quel manque d'entrain de RedHat envers OpenSolaris...
Les devs Sun servent beaucoup linux et RedHat en particulier quand même : OpenOffice, OpenJDK, Gnome (le HIG par exemple doit beaucoup à Sun, idem pour le dernier gdm par exemple).

1/ Sun ne fait pas Solaris contre Linux, je ne sais pas ou tu l'as vue jouée celle là, mais Sun fait Solaris pour Solaris, parce que c'est un OS qui plait à beaucoup de monde et de boîte. Sun fait aussi du linux et du Windows... tout comme IBM fait AIX, Linux ou Windows
2/ Il n'y a pas de compatibilité linux juste des softs GNU et IBM qui rajoute un L à AIX pour le marketing.
3/ Solaris dispose lui par contre d'une compatibilité binaire avec Linux qui marche pas trop mal : BrandZ (basé sur les zones ce qui rend le truc encore plus sympathique)

Actuellement sous FreeBSD-CURRENT, et dans une semaine sous FreeBSD-STABLE, il y a la bonne version qui va bien des DRMs, donc vous pouvez déjà bénéficier de ces nouveaux drivers.

Je suis dans la merde alors tous mes disques ont largement plus de 3-4 ans et ont travaillés pourtant il font toujours leur boulot sans rechigner.

donc durée moyenne de 3-4 ans, ça m'intéresse de savoir d'où vient se chiffre...

Sinon bien sûr qu'il faut toujours backuper les données auxquelles on tient.

De toute manière, les nouveautés de Bash 4.0 n'ont pas de quoi faire migrer les utilisateurs de ZSH qui bénéficient depuis des lustres de ces fonctionnalités.

Par contre pour ceux qui veulent migrer vers ZSH choisissez bien une distribution qui ne maltraite pas ses utilisateurs en packageant uniquement la version 4.2 qui est quand même ultra vieille alors que la 4.3 est parfaitement stable et plus agréable (notamment à cause de l'unicode)

mais non tu n'es pas seul je fais de l'activisme aussi :)

C'est vrai que tu es un peu violent mais c'est tellement vrai :)

from file in new DirectoryInfo(@"/etc").GetFiles() select file.Name;

pfiou bah je ne suis pas prêt de quitter mon zsh

La majeure partie des besoins de stockages ne concerne pas la bureautique et encore moins Windows, il faudrait peut-être que tu ouvre un peu les yeux sur le marché.

BTRFS sera peut être en version 1.0, mais sera-t-il utilisable sur autre chose que linux ? parce que une version de ZFS parfaitement utilisable sur son OS d'origine on l'a déjà :)

Ce qui m'intéresse c'est d'avoir un bon FS le plus interopérable possible, je ne pense franchement pas que BTRFS sera interopérable (je souhaite que oui quand même) ZFS l'est lui et le sera de plus en plus.

Renseigne toi, tu ne peux pas faire de XFS sur un BSD, le ports de XFS sur FreeBSD est en RO uniquement et la version même expériementale en écriture n'a jamais été au bout, et non, toutes les fonctions du FS ne marche pas, sous freebsd : pas de journalisation, pas d'écrite donc bon question fonctionnalité : out.

XFS est linux-only : IRIX est mort, et je ne suis pas certain (à voir) que les versions actuelles du XFS soit compatible avec la dernière version d'IRIX : 1998.

Quand aux ACL, je ne bosse jamais sur des trucs orienté bureautique, j'ai donc très rarement eu besoin des ACL donc dire que 97% du marché en a besoin c'est n'importe quoi, j'ai bossé sur beaucoup de gros projets avec des énormes besoin de stockage et je n'ai que très rarement eu besoin d'avoir recours aux ACL, donc oui les ACL manque mais ne sont absoluement pas indispensable à la popularisation du FS. Dans tous les cas je ne parlais pas d'utilisation "à la maison".

Ce que nous avons actuellement n'est pas approximatif, mais est parfaitement utilisable, les ACLs viendronts et seront aussi parfaitement utilisable...

J'adore l'argument du ZFS sera cantonné au seul et unique solaris, alors que tous les FS linux sont jusque là restés cantonnés au seul et unique linux.

Il suffit de regarder les ports des FS linux sur les autres Unix et Unix-like libre : Solaris, *BSD, il n'y a rien d'aussi avancé que ZFS en terme de multi-OS. ZFS est utilisable sous freebsd (je l'utilise beaucoup) il est utilisable sous linux via fuse (même si ce n'est pas parfait), il est en cours de portage plus ou moins avancés sur Apple et NetBSD, il manque certes quelques fonctionnalités pour pouvoir l'employer dans tous les domaines (ACL par exemple), mais dans beaucoup de cas ce n'est pas indispensable et le support en cours de toute façon. Aucun FS linux ne peut (à ma connaissance - merci de me signaler si je me trompe) justifié d'un tel support en dehors de son OS d'origine.

Linux/*BSD

bah ouvre un peu des yeux, ZFS commence déjà à être populaire sous FreeBSD, un portage NetBSD est aussi en cours, un versio fuse existe aussi.

Le but de ZFS est justement le portage et SUN a depuis le début encouragé le portage sous d'autres OS (un portage sous OSX existe aussi)

Merci pour toutes les réponses, je comprends mieux :)

Je vais essayer de builder une version récentes pour ne plus avoir le jni, et si ça me marche je fait un retour rapide avec un patch pour avoir une version posix du script de démarrage :) et si c'est bon il y aura surement rapide un ports freebsd

Juste un rajoute plutôt 2 war un pour le backend et un pour le frontend afin de toujours pouvoir les dispatcher sur plusieurs serveurs.

J'ai quelques interrogation sur l'architecture logicielle de MiniG (sans être rentré en profondeur dans les entrailles du softs).

DISCLAIMER : je trouve l'ui vraiment bien et je suis très intéressé par le soft.

1/ quel est l'intérêt de séparer deux exécutions java pour minig : le backend et le frontend, sachant que tomcat au démarrage de l'application peut lancer le backend sans soucis dans sa propre instance java, ça complexifie le déploiement alors qu'il me semble qu'un simple war pourrait faire l'affaire.

2/ quel est l'intérêt d'utiliser des morceaux d'eclipse qui utilisent du jni ça limite fortement le "run everywhere", en effet sur mon FreeBSD je me retrouve obligé de recompiler des morceaux d'eclipse pour avoir eclipse_1020.so et eclipse_1115.so afin de tester les snapshots mis à disposition. Est ce que l'avantage des bibliothèques d'eclipse utilisées (celle qui nécessite le jni) est si important au niveau de la facilité de code qu'il est *vraiment* plus inétressant de les utiliser ? je trouve que ça complexifie le packaging (je voudrais faire un ports FreeBSD) et limite la portabilité.

3/ le backend (dont je ne comprends toujours pas pourquoi il ne tourne pas directement dans tomcat :)) utilise un script bash pour démarrer alors qu'un script shell posix ferait largement l'affaire (enfin ça je fournirai un patch dès que j'aurais compris l'intérêt de ne pas mettre le backend dans le tomcat).

4/ Pourquoi des chemins vers des fichiers de configurations en DUR et très linux-only (/etc/...) pour le packaging FreeBSD moi j'aurai je voudrai les mettre dans /usr/local/etc/minig par exemple (enfin ça doit pas être trop compliqué à mettre en oeuvre.

il serait vraiment intéressant pour minig de ne fournir qu'un seul war a déployé (même si à l'intérieur il y a une séparation backend frontend) ce serait beaucoup plus simple à mettre en oeuvre tester et tout.

Dans l'ideal un soft comme ça ce que je trouverai intéressant c'est un war unique que l'on déploie.
Il gère sa conf dans son WEB-INF.
Il détecte une première installation en fonction de la présence ou non de son fichier de configuration ou une upgrade qui nécessite des changements de conf en fonction d'un tag (de version par exemple) dans son fichier de conf et qui lorsque l'on pointe le navigateur dessus propose un wizard pour faire tout le nécessaire.

J'imagine que ce serait plus simple.

J'espère que mon post est compréhensible et que les devs comprennent bien que je ne crache pas du tout sur minig, j'essaye d'être constructif et de comprendre une archi qui de prim'abord me parait étonnante.

Je le trouve très très intéressant comme webmail.

Si tu prends cette news http://linuxfr.org/2008/02/28/23772.html , ton commentaire "Pas pu attendre vendredi...." moi j'appelle ça de la bave, et c'est loin d'être le seul exemple.

Tiens c'est marrant ça me rappelle mes news freebsd ...

le problème de llvm c'est qu'il est pour le moment incapable de se bootstrapper lui même (dev en C++ et pas de compilo C++ officiel - autre que llvm-g++ - pour le moment - CLANG n'est pas près de faire du C++), ce qui est quand même gênant pour les projets bsd. De plus LLVM est intéressant pour les ports et toutes les applis tierces, mais un "simple" et "petit" compilo C efficace est plus intéressant pour les projets BSD.

Mais n'est craintes beaucoup de dev BSD sont intéressés par LLVM (en particulier chez FreeBSD).