Bapt a écrit 772 commentaires

J'entendais par bien gérés, c'est qu'il me fera des fichier odt propres. Après l'Interface est limitée en fonctionnalité, et je ne pourrai pas faire tout ce que je peux fait avec OpenOffice, je le sais bien.

En fait doc.google.com ancien writely utilise openoffice en arrière plan.
Il suffit d'enregistrer en pdf depuis writely et doc.google.com et de vérifier les propriétés du document généré pour lire que celui-ci est généré par OpenOffice.org 2.

Bref au moins je suis sur que mes documents OpenDocument seront bien gérés :)

Il est intéressant de voir ce que va devenir ce fork dans l'avenir. Quels choix technique vont être pris une fois le code de la mofo avalé (long processus AMHA). Ce que j'aimerai bien, c'est un allègement drastique de firefox, et un développement plus orienté Unix (moi aussi j'ai le droit de lancer des trolls :) ).

Cela n'a aucun intérêt si IceWeasel ne fait que rester synchrone avec firefox en changeant les icones et le nom.

Ca tourne sur linux, ou un BSD de manière légale ??? non ??
Ben alors non je ne peux/veux pas l'essayer. M'en fou quoi, j'en pense rien.

Et le prochain MSN il sort quand ??

Je sais que ce commentaire est certainement inutile (en bas à droite :)), mais je trouve aussi ce journal inutile, surtout en première page. J'en ai marre de voir des annonces pour des technos 100% MS dont on se fout à priori sur LinuxFR.

Je sais aussi que l'on dit ce que l'on veut dans les journaux.

non, je le ferai pour la version finale quand elle sera prête :)

Oui ça fait quelques semaines, mais quand ton quelques il est long :)
la 10.2 est sortie le 14 septembre 2005

Pour montrer qu'elle est vivante tu devrais plutôt dire que la 11 va sortir d'ici peu et que la RC5 est sortie le 18 septembre 2006.

Merci beaucoup, je vais regarder de ce côté là.

Je me serait donc mélanger les pinceaux concernant freebsd-update à cause du site et du blog de Colin Percival, car il fournit régulièrement des script permettant de monter de version :
mise à jour de 6.0 vers 6.1 par exemple : http://www.daemonology.net/blog/2006-06-29-freebsd-6.0-to-6.(...)
Par contre je ne sais pas d'où est sortie l'idée que j'avais que c'est un SoC ... Tant pis ça m'apprendra à revérifier mes infos avant de poster :)

Non KSH n'est pas sous license BSD, il était sous license propriétaire AT&T et mis sous license CPL en 2005 (cf wikipedia anglais). En revanche, je viens de me rendre compte que les deux exemples que j'ai donnée ZSH sous licenses ZSH (quasiement BSD) et PostgreSQL sous license PostgreSQL (quasiement BSD).
ZSH : http://sources.gentoo.org/viewcvs.py/*checkout*/gentoo-x86/l(...)
PostgreSQL :
http://sources.gentoo.org/viewcvs.py/*checkout*/gentoo-x86/l(...)

Dans tous les cas je ne vois pas ce que ça change appart si il y a une vindicte populaire des libristes contre la license BSD et ces variantes.

Mono est bien sous license MIT et est poussé par beaucoup d'acteur du monde libre non ?

Oh il est beau celui-là, tant pis je marche dedans...

La grosse différence entre le développement de FreeBSD et de Linux, c'est que tout les commits ne sont pas mis dans le relnotes, seules les parties visible (intéressante) donc forcément le relnotes est moins important que celui de linux. Le nombre de développeurs est quand à lui aussi beaucoup moins important, ce qui expluique peut être aussi moins de code produit.
Maintenant j'utilise FreeBSD au quotidien, et tout mon matos est reconnu, aucun soucis de ce côté là, les évolutions sont douces et suivent le marché (peut être un tout petit peu moins vite que Linux mais quand même) ce qui me convient très bien, pas de mauvaise surprise à l'update du genre oups j'ai mis à jour mon kernel, mais udev ne marche plus.
Les API ne sont pas cassées tous les 4 matins (j'ai dit que je marchais dans le troll) ne nécessitant par de recoder tout ou parti des drivers dépendant (donc moins de code nécessaire).
Quand une techno rentre dans le kernel, elle y reste pour un moment, car elle est mûrement réfléchit et codée en conséquence (API comprise) donc pas besoin de la modifier régulièrement : exemple devfs fait très bien sont boulot et les modifs sont mineurs comparées à celle de udev qui sont cassées régulièrement (devfs et udev sont userland et hors kernel, mais très dépendantes du kernel).

Je connais Linux depuis bien plus longtemps (et beaucoup mieux) que FreeBSD et apprécie aussi la rapidité de développement de ce dernier, mais je suis aussi saoulé de voir régulière des modifications de fonds sur des fonctions importantes du noyaux qui peuvent généré des bouleversement de mon système. Mon niveaux en programmation kernel est trop faible pour en tirer de réelles conclusion et surtout pour juger les développeurs, et je ne doute pas de la qualité des développeurs kernel linux (bien au contraire) en revanche je doute sur la métodologie appliquée quand à l'étude des solutions apportées. Mon impression (peut être loin de la réalité) c'est que sous linux on discute de l'idée, on est d'accord, puis on dit vas y implémente. Ensuite on se dit, l'idée est toujours bonne, mais il y a une erreur de conception là on ne peut pas faire X. OK on casse et on le recode en partie, tant pis pour les inpactes. Sous FreeBSD on discute des technos, on fait la conception ensemble pour regarder tous les inpacts et ensuite on dit vas y code. Quand on l'intègre il y a rarement besoin de revenir dessus. Je me doute bien que ça ne se passe pas tout le temps comme ça, mais c'est le sentiment que j'ai.

Pour finir, mon utilisation perso de ma machine sous FreeBSD et sous linux est identique (même avec des trucs modernes : Camera DV, Téléphone en bluetooth, etc.). Donc si FreeBSD code moins pour arriver au même résultat, tant mieux pour eux et pour moi.

De rien :)
sinon syscall=>appel système, tout bêtement, c'est marrant comme on ne voit pas les choses les plus simple :)

La plus grosse demande en terme de SGBD n'est pas les hébergeurs, ce sont les plus visible, et je suis bien d'accord avec toi que MySQL correspond bien à la demande des hébergeurs, et du Web en général (intranet y compris)
En revanche, les grosses demande en terme de SGBD sont les applications métiers : spéficiques à chaque coeur de métier, spécifique à la gestion d'entreprise, ou autre qui ne sont pas forcément Web, et dans ces niches là, MySQL ne répond pas aux attentes : tu y retrouve du Oracle, Sybase, et autres SQLserver, avec un peu de chance tu trouve du PostgreSQL (pas assez mis en avant par le libre pour être connu et mis en place.). Les applications en question sont souvent de grosses applications complexes avec des utilisations complexe du SGBD, et utiliser MySQL dans ces conditions revient à allourdir considérablement le programme pour gérer ce que MySQL ne gère pas encore. Et les applications libres dans ces niches là utilisent majoritairement MySQL, ou alors au choix MySQL ou PostgreSQL mais avec un PostgreSQL qui n'utilise pas ces fonctionnalités les plus intéressante car il faut garder la compatibilité avec MySQL.

Ce genre d'application n'est pas forément visible par tous, mais c'est un point crucial dans le SI d'une entreprise, et représente souvent des utilisations complexes du SGBD.

mysql a aujourd'hui toutes les fonctionalites qu'on peut demander a un sgbd.

C'est marrant c'est la fameuse phrase dont je parlai tout à l'heure : "Qu'est ce que MySQL a et que PostgreSQL n'a pas ?" :)
Réponse encore beaucoup de chose (la liste est trop longue) et d'autre beaucoup plus qualifié que moi pourront te répondre, mais par exemple dans mon boulot (je ne suis pas DBA) j'attend d'un SGBD qu'il puisse avoir entre autres
- vues (je ne sais pas ce qu'il en est pour MySQL)
- gestion des contraintes (plannifié pour la 5.1 de MySQL)
- curseurs (seulement en Read-Only dans MySQL 5)
- les triggers.
- les tablespace (je ne sais pas ce qu'il en est non plus pour MySQL)

Le tout en version stable de production. MySQL ne répond pas à cette demande qui pourtant les autres SGBD "sérieux" du marché opensource ou pas le font. Je suis d'accord que l'écart de fonctionnalité se réduit (comme je le dit dans mon journal), mais il y a encore de la marge.

Oui depuis l'arrivé de Linux qui ne proposent pas par défaut de ksh, les scripts redescende au plus petit dénominateur commun, cad sh qui est souvent un lien vers le shell par défaut. Heureusement il y a des normes implémentées par presque tous les shell, et donc faire du sh est portable.

Il n'y a pas quer le vi-mode, il y a aussi le emacs-mode :)
Sinon je suis d'accord que beaucoup de gens lance bash en première commande sur les unix proprio (si il est dispo), mais les scripts restent en ksh

Bash est un peu plus ancien que ZSH (1987 vs 1990 - cf wikipedia)
Bash n'a pas su s'imposer face à ksh, en entreprise tu trouves beaucouop de script KSH car KSH est beaucoup plus qualifié pour faire ce genre de chose (comme ZSH) que BASH, ce qui est de moins en moins vrai. et KSH est souvent le shell par défaut des unix propriétaires (mais de plus en plus souvent bash est proposé en plus).

Le problème que tu évoques concernant ZSH est le même pour Bash, Bash n'est pas disponible partout... Il a été mis par défaut dans beaucoup de distribution linux (toutes ?), mais n'est pas par défaut sous les BSD par exemple, encore moins sur les unix propriétaires, etc.

Le problème que tu évoques concernant Bash, il est partout par défaut je code donc en bash tu peux le généralisé. Je choisit mes OS parce qu'ils sont libres, mais aussi avant tout parqu'ils repondent mieux à mes besoins technique, et si je fait du dev, je le fait avec ce qui répond au plus à mes besoins techniques, selon les cas : fiabilité, évolutivité, complexité, portabilité... Ensuite j'installe le nécessaire sur toutes les machines cibles.
Si je reprends ta phrase dans un contexte sans équivoque pour tout le monde ici :
Utiliser Linux, c'est se retrouver démuni lorsqu'on arrive sur une machine qui n'a pas Linux installé.
ou
Utiliser Bash, c'est se retrouver démuni lorsqu'on arrive sur une machine qui n'a pas bash installé.
Bref, je crois que l'utilisateur raisonnable ne cherche pas "toutes les fonctionnalités", mais "celles qui lui conviennent", c'est très différent :)
Je ne pense pas, et mon étonnement est là sinon les deux exemples que je prends n'aurait pas suivit un développement qui tend à les rapprocher de leur concurrent plus aboutit fonctionnelenement. Si la direction prise est celle là, c'est bien que les fonctionnalités offertes ne convenait pas.

Donc pourquoi s'emmerder avec des trucs qu'on utilisera pas?

Dans les deux cas que je présente des projets dont l'évolution montre que les fonctionnalités en question veulent être utilisées, et ont été implémentées. Bash n'avait pas de completion avancée, et le projet bash-completion a vue le jour et a été intégré. MySQL au fur et à mesure de ses version implémente ses manques par rapports à PostgreSQL. Donc c'est bien qu'elles veulent être utilisées.

Bref, ranapété que ca fait plus de choses, avant tout : est ce que ca fait ce que moi je veux, comme je le veux?
Si la reponse est non, pas la peine d'aller plus loin, candidat suivant.

Oui et non, je ne parle pas de l'intérêt d'avoir des projets concurrent plus ou moins avancés qui présentent volontairement des fonctionnalités moindres, ou même des fonctionnalité équivalente. Je parle de projets qui tendent à fournir les mêmes fonctionnalités, la coéxistance des deux est saine, et pousse à la concurrence donc l'amélioration. Mais je pense que le projet le plus abouti devraient être mis en avant. Regarde dans le cas des SGBD combien de programmes libres complexes utilisent MySQL alors qu'ils auraient largement bénéficiés de l'utilisation avancée de PostgreSQL, ils utilisent MySQL car c'est le SGBD mis en avant, et donc le plus répandu (l'inverse est vrau aussi, serpent qui se mort la queue).

Tout les projets libres n'ont pas forcément les moyens d'un communication forte, c'est aux autres acteurs de le faire dans ces cas là : intégrateur, editeurs de distrib etc.

L'algorythme est libre et tu as une implémentation de référence sous license libre, de plus, tu as mets un port unix libre. Donc si tu veux réimplémenter 7zip rien ne t'en empêche, si il est bien tu feras sans doute des heureux.

Moi la version p7zip me va très bien, car elle est synchronisée avec la version de base (sous windows) et donc suit de très près les fonctionnalités ajoutées à ce dernier. Je n'ai pas regarder le code, je ne sais pas si il est dégueux comme tu le dit, mais il me satisfait très bien et sans doute les développeurs de p7zip.

Ce qui serait intéressant, ce serait de faire des wrapper :
unzip, zip, unrar qui appelerait 7z ainsi tout les progs GUI ou autres qui utisent unzip, zip, ou unrar n'aurait plus qu'une seule dépendance, 7z (libre qui plus est.)

Ca à l'air intéressant, je vais regarder ça. Je ne connais pas smalltalk, ça me permettera d'apprendre.

Je n'ai rien dit de tel dans mes propos.

Je tenai juste à souligner que gentoo n'a pas attendu que ati ou nvidia sortent un driver xorg 7.1 avec de la mettre à dispo pour les utilisateurs en unstable, en revanche ils l'ont fait pour les utilisateurs en stable ce qui est logique.

A noter aussi que l'un des points génant pour l'adoption de zsh était le support de l'utf8 ce qui est résolu depuis les version "instable" 4.3 intégrées dans la plupart des distributions, le support n'est pas encore parfait (support uniquement dans le CLI et pas encore pour le code).

A noter aussi que ZSH est capable d'émuler le comportement des shells existants : le bourne shell, CSH et KSH. Permettant dans beaucoup de cas, une migration des scripts existant avec peux de modification.

Pour le faire dans le code : emulate -L ksh.
Sinon faire un lien symbolique de /bin/zsh vers /bin/ksh par exemple et utiliser directement #!/bin/ksh dans son script.

En parlant des applications e17 utilisant ETK ou EFL, se serait intéressant de tenir un listing de ces dernières et de leur status de développement ALPHA, BETA, ..., STABLE, ainsi que de leur utilisabilité : inutilisable/instable/.../utilisable/stable

J'ai bien trouvé ça http://www.get-e.org/Resources/Applications/ mais escape n'y est par exemple.

Autre question exhibit peut choisir entre ewl et etk c'est quoi la différence entre ces deux toolkits ?

Ce que je cherchais c'est un toolkit "basique".
Les frameworks complets de :
Turbogears, Django, RoR, Catalyst, Jifty : Très bien, (j'ai un préférence pour les deux derniers perl oblige :)), mais il reste du code HTML, même léger, ça ne répond donc pas à mes attentes, même si ça minimise fortement le temps passé sur cette partie là. De plus c'est bien pour des gros projets, mais si je veux faire uniquement des séries de wizard dans le but de pondre du PDF par exemple, c'est un peu trop gros.
ASP.NET (en C#) : je suis bluffé, c'est exactement ce que je cherche, mais il y a un bémol : mon serveur de destination est FreeBSD est ce n'est pas encore très très stable sur FreeBSD.
GWT : pas complètement libre donc je n'en veux pas.
Frameworks java : difficile à mettre en oeuvre avec un jvm libre (au moins sur FreeBSD :( )
Pyjamas : à l'air bien, mais pas encore de release officielles :(

Bref J'attends encore que Pyjamas soit finalisé, que ASP.Net (mod_mono ou XSP) soit stable sur FreeBSD (je le garde de côté pour tester sur des serveurs sous linux). Dommage que d'autre langage n'est pas repris le principe de ASP.NET (codé en C# par ce que coder directement des fichiers aspx ne me convient pas).

C'est étonnant je ne pensais pas être le seul à vouloir m'affranchir de la "galère" xhtml/javascript/css/support par les différents navigateurs pour me focaliser sur le code. C'est pas grave je vais encore attendre un peu.