À mon boulot http://www.sgul.ac.uk , on a testé et c'est parti, on embauche une boîte pour l'install et le support, on installe le connecteur Outlook, Horde et c'est parti.
On pense pouvoir rouler dans moins de six mois. 10000 utilisateurs et intégration avec notre LDAP en Fedora Directory Server, nous avons financé le connecteur Kolab <-> FDS (c'est dans la release).
Je repasserai avec retour d'expérience, mais je suis très confiant, je voulais du libre et du costaud, et c'est la seule solution viable qui assure.
Faut pas croire que c'est gratuit cependant, comme toute grosse organisation, nous devons avoir un contrat de "support", qui ne sert à rien mais qui est obligatoire et on parle de 50k £ / an, ce qui est bien moins que pour Exchange mais pas donné quand même.
Il n'y a que moi qui suis passé à Fedora de Mandriva (fidèle depuis la 8.0)? Pourquoi?
- Firefox me fait passer par le club pour installer Flash, je suis pas membre, ca marche pas, voilà bien un patch à la con.
- les RPMS sont incompatibles, même les src de Mandriva ne compilent pas avec Fedora, les fichiers .spec ont une syntaxe différente! Bien malin ca aussi.
- les paquets x86_64 ont des noms bizarres: lib64... pourquoi n'avoir pas suivi Fedora pour ca non plus?
- Mandriva libre ? Moins que Fedora.
Et laissez Red Hat en dehors de tout ca s'il vous plaît, Fedora, c'est la première distro totalement communautaire qui marche vraiment du tonnerre, on ne doit pas attendre la nouvelle version de la DISTRO pour avoir la nouvelle version d'un PROGRAMME.
Moi, j'utilise plus que ca, et bientôt je vais la mettre sur des serveurs de prod (<perso>parce que la version de Zope est récente</perso>), en dépit de la garantie "support" de Dell qui impose une RHEL.
J'aimais bien urpmi, mais yum, c'est pas mal non plus faut dire.
Mais ce que j'aime avant tout, c'est l'aspect vraiment libre du projet: pas de softs non libres (poussé à l'extrême, cf le mp3) et une gestion totalement communautaire (avec RedHat derrière mais très effacé). La réactivité est au rendez-vous. C'est toujours plus facile de compiler des softs beta sur Fedora que sur Mandriva, pas besoin de passer par le cooker pour compiler AIGLX, toutes les bibliothèques de dev sont là, par ex.
Pourquoi Mandriva ne reprendrait-elle pas Fedora Core pour la cuisiner à sa sauce et vendre du support orienté bureau, comme le fait Yellow Dog. Tout le monde y gagnerait: avoir un "Core" commun et réactif et ensuite faire du business autour de ce core. Pourquoi donc?
Plusieurs fois, il ne découvrait pas les ressources du serveur, et en fonction de la version d'Outlook, il fallait faire l'installation différemment.
J'ai essayé sur trois machines, si ca marchait du premier coup, bon, sinon, j'ai eu beau désinstaller et réessayer, pas moyen. C'est comme si il avait pollué le registre une fois et qu'il ne nettoyait rien.
J'ai pas réussi à faire deux bonnes installs d'un coup, alors j'ai abandonné.
En plus, le connecteur Outlook ne se connecte pas au serveur Opengroupware, il se connecte au serveur Skyrix, qui doit être installé aussi en parallèle sur la même machine et se sert des mêmes données et fichiers de configuration que la version libre qui ne sert plus qu'à l'interface web et au "GroupDAV". Pas super propre tout ca.
Chez nous (10 000 utilisateurs), on n'utilise que du Unix en serveur. Nous sommes tous allergiques à Windows alors nous avons un Samba pour l'authentification et les fichiers. L'email est en IMAP et nous ne proposons pas de solution calendrier, sinon celle de SunONE qui est pourrie et propriétaire.
C'était ma mission de tester des systèmes groupware libres et de voir leur capacité d'intégration et de modification à notre sauce pour remplacer notre SunONE tout fermé.
Et bien, j'ai encore rien trouvé mais je me suis lancé sur OpenGroupware et j'ai fait un thème maison. J'ai aussi essayé le connecteur outlook (propriétaire et payant) qui marche vraiment pas bien. En plus le code est en Objective C et les templates HTML sont partie template, partie généré, sans séparation claire.
Avant ca, j'avais essayé OpenXchange, imbuvable, l'install ressemble à un parcours du combattant et le code ne ressemble à rien. Au moins OpenGroupware proposait des rpms et s'installait tout seul.
C'est du passé de toute facon car depuis que je suis passé à Fedora Core 5 sur le serveur de dev, Opengroupware ne marche plus, son "module" apache étant incompatible avec Apache 2.2... Je pense laisser tomber et je vais me rabbatre sur Kolab en espérant que ca marche.
Chez nous, on ne veut pas forcer les utilisateurs à utiliser tel ou tel programme, ils veulent Outlook, ils l'auront. De plus il faudrait une interface web, que nous pouvons modifier et intégrer dans notre intranet. C'est pour ca qu'on veut de l'open source.
Jusqu'ici, rien, et les solutions ex-propriétaires n'en sont vraiment pas, en tout cas pas pour mon cahier de charges. Peut-être iCal server?
Bonne question qui est apparue sur Slashdot il y a peu.
La réponse est simple: liberté de choix, tu pourras utiliser les plug-ins Fluendo ou non, en passant par PLF ou Livna. (Il y a déjà un autre plug-in mp3 pour GStreamer)
Il faut malheureusement respecter les règles pour pouvoir distribuer certains programmes soumis à des licences, notamment aux États-Unis. C'est pourquoi pour l'instant, Fedora et Red Hat EL sont livrées sans décodeur mp3. Il est interdit de livrer un décodeur mp3 aux E.U. sans payer une licence à Thomson (bien qu'ils ferment les yeux sur les FLOSS en général).
Avec le plug-in mp3 de Fluendo, Fedora pourra finalement contenir un décodeur mp3. Le plug-in licencié est binaire mais le code est disponible sous licence MIT.
Il en vaut de même pour tous les codecs soumis à brevets ou licence. En gros, en Europe, nous on s'en fout mais les distributeurs seront heureux de pouvoir proposer ces fonctionnalités "out of the box".
Ca protège les distributeurs et ca n'affecte pas l'utilisateur final. Où est le problème?
L'aspect négatif, c'est que on poussera moins l'utilisation de codecs libres comme Vorbis ou Theora, puisqu'on pourra lire des WMA et des AAC.
J'avais pense a la solution pGina mais cela ne peut faire l'affaire que si l'on controle les postes clients et ce n'est, heureusement, pas la politique de la maison: chacun fait ce qu'il veut de sa machine.
pGina ne comporte pas d'aurtes avantages sur une solution winlogon NT4 basee sur Samba que la customisation. Nous avons trouve cela inutile, puisqu'il nous est plus facile de travailler cote serveur, scripts, backend LDAP...
De plus pGina ne supporte pas (officiellement) Kerberos donc franchement je n'en vois pas l'utilite car si on a du Windows dans son organisation on a forcement un serveur Samba pour les fichiers et l'impression. Ce serveur peut aussi fonctionner comme un serveur d'authentification donc meme resultat avec moins de boulot et pas de changement cote client.
L'avantage de AD sur NT4 c'est l'implementation de Kerberos, c'est ca qui est important. Et Samba 4 implemente cela. Donc encore une fois: pas de changement cote client et administration serveur facile pour des unixiens.
Il existe bien Kerberos for Windows du MIT mais les applications Microsoft (dont IE et Outlook) ne permettent pas d'utiliser une autre bibliotheque kerberos que celle du systeme. Ca marche avec Eudora et Firefox mais comment dire a notre departement cravattes costumes de finances qu'on ne supporte pas Outlook?
Dans mon equipe on fait comme ca et on n'a meme pas un admin Windows!
C'est une excellent nouvelle car jusqu'à présent, pour pouvoir intégrer des machines sous Windows à un réseau d'entreprise, soit on passe par une pièce Microsoft: Active Directory, soit on continue d'utiliser les domaines NT4 avec Samba.
L'utilisation de Samba 3 n'est pas optimale car on n'a pas accès au "Single Sign On" qui a été introduit par Microsoft avec l'utilisation de Kerberos par Windows 2000 Active Directory. L'utilisateur doit cacher ses mots de passe ou les re-taper.
Et non, il n'y a pas plusieurs façons de s'authentifier sous Windows, soit on a les utilisateurs listés en local, soit on fait partie d'un "domaine" Windows (soit on utilise une solution propriétaire bien chère). Le local, quand on a plusieurs milliers d'utilisateurs, c'est impensable. Et unse solution propriétaire, c'est se lier les mains.
Chez nous (plus de 6000 utilisateurs), on est en tout Unix (Linux et Solaris) pour les serveurs et on ne veut pas de Microsoft, résultat, on est obligés de rester en NT4 avec tout les problèmes que cela implique. On voulait passer à Kerberos pour avoir le Single Sign On et la seule solution, c'est de mettre un serveur AD dans notre parc. Pas bon ça. Par principe, dans les faits, ce serveur ne serait qu'une copie de notre Fedora Directory LDAP et l'authentification se ferait par un Kerberos KDC MIT.
Tout cela aurait été plus simple si MS avait implémenté Kerberos à la lettre (sans ajouter ses petites features non-documentées) et si le schéma et le protocole LDAP de AD était public...
Cette nouvelle version de Samba va régler mes problèmes de conscience! En plus d'ajouter de la sécurité à notre réseau.
Pas totalement d'accord, d'abord, on paie Microsoft chaque année pour les clients mais le gros des dépenses dans un tel cadre risque de partir dans Windows Server et MS Exchange. Pour ça, le boss de IT y a réfléchi à deux fois. Et on se retrouve à devoir supporter des clients MS avec des serveurs Linux et Solaris, avec tous les problèmes que cela apporte.
Open Exchange est loin d'être un vrai projet Open Source et il faut se lever tôt pour l'installer. Quant à Samba, je ne suis pas un expert mais ça a l'air moins simple que NFS faut avouer.
Ce rapport est encourageant mais en Grande Bretagne, où je travaille, le libre ne décolle pas vraiment. Même Firefox n'a pas vraiment pris sa place, contrairement au EU et au continent.
C'est dérangeant, je ne sais comment pousser mes utilisateurs à accepter Firefox comme navigateur standard sur les postes. De là à passer en Linux sur poste client, il y a un gouffre.
Ici, tout le monde utilise Windows et a l'impression que c'est ce qui se fait de mieux car ils croient comprendre ce qui s'y passe. Maintenant, ils veulent IE, Outlook et Exchange.
Même chez les admins, mes collègues ont soit un dual boot, soit deux stations. Je ne sais pas ce qu'ils font avec le Windows mais ils s'y connectent fréquemment.
Pareil pour nos serveurs, on a du Solaris et on garde du Solaris. Personne ne parle de migration vers des solutions libres. Même si on doit compiler les logiciels sur Solaris, on les compilera (au lieu de faire "yum install" et bien sûr "yum update"). On a ausi du Sun pour le LDAP et pour le IMAP, pas question de changer. Solaris, c'est bien(TM).
Autant on a l'impression de vivre à la pointe de l'IT ici, autant on perçoit un conservatisme sous-jacent. Je ne sais pas quoi faire pour avancer l'idée d'une migration. Quelqu'un a une idée?
> David Hyatt ancien Mozillien font du proprio chez Apple...
Mmm, il travaille surtout sur Webcore, en LGPL.
Donc je ne suis pas tout à fait d'acord avec ta justification de la nécessité de travailler. Il faut bouffer, oui, mais on peut choisir où on fait ses courses.
Pour ma part, j'ai toujours programmé avec du libre -- des logiciels à usage interne ou sur commande (ce qui correspond à plus de 80% du marché du logiciel. Ouais, c'est ça du logiciel, pas ce qui s'achète à la FNAC). Et j'ai toujours programmé et déployé sous des systèmes libres que ce soit du J2EE sous JBOSS ou du C++ avec gcc ou du script des plus variés sous Linux.
Le mec il a choisi d'aller chez crosoft, et la meilleure justification semble le pèze plus qu'autre chose sinon pourquoi aller chez l'ennemi des idées que l'on défendait il y a peu?
Vous savez combien on lui a offert chez crosoft? C'est un salaire annuel à six chiffres?
Pour info, Linus gagne 200k $ / an (lu dans BusinessWeek), alors le gars Robbins il a bien dû se laisser tenter par quelque chose du genre, non?
Ceci dit je n'ai aucune preuve de ce que j'avance et peut-êtr bien qu'il part chez crosoft comme un évangélisateur, j'en doute...
Pas tout à fait d'accord. L'introspection dans GObject s'apparente à la réflection dans Java. C'est une API de GObject.
Ce qui signifie que l'on n'a pas besoin des sources de la librairie à analyser, on n'utilise que des appels GObject.
Glade fonctionne d'ailleurs comme ça. Il fouille les objets de Gtk+ pour en extraire les propriétés et les signaux et ensuite permettre leur modification via sa GUI. C'est bien plus que simplement trouver les méthodes et les champs publics. GObject, c'est JavaBeans aux stéroïdes.
De plus GObject permet aux bindings d'étendre les types GObject et aussi de passer des fonctions dans leur langage aux signaux. Ça va très loin. La création de bindings automatique n'est q'une utilisation de cette introspection, Glade en est une autre et qui sait, un IDE pour GObject...?
GCJ compile le bytecode en .o sur pas mal d'architectures.
Le problème de GCJ, c'est les bibliothèques, pas la compilation, ça c'est au point.
Tu peux même compiler directement un .jar: gcj -shared my.jar -o lib-my.so, et la JRE de GCJ peut même charger ton .jar compilé au runtime avec Class.forName(), il y a une convention à respecter pour le nom de la lib et il faut que la lib soit dans le $LD_LIBRARY_PATH
Donc oui, théoriquement, tu peux prendre un programme Java Bytecode et le compiler en natif pour une plateforme supportée par GCJ et pour laquelle il n'y a pas de JVM proprio dispo, comme Linux PPC par exemple... Mais il faut que ce programme soit "pur" Java (pas de code natif JNI) et n'utilise que ce qui est supporté par Classpath. Tu peux alors avoir Tomcat sur Linux PPC, par exemple.
Attention cependant: GCJ ne supporte pas toutes les architectures de la même façon et en supporte moins que GCC.
Les classes sont chargées en mémoire puisqu'il s'agit d'un interpréteur. Et en plus, lorsque la JVM précompile certaines parties de code (avec le JIT), elle les cache en mémoire aussi.
Donc, on garde en mémoire les classes (.class) -- même celles qu'on n'utilise pas car les .jar sont chargés en entier (pas sûr)--, les dictionnaires (méta-données) des classes (nom de classe, des méthodes, des champs + accès), les bouts de code précompilés. C'est lourd tout ça... Mais il n'y a que la mémoire qui soit affectée, pas les perfs. Et tout se situe au niveau de la JVM, c'est pour ça que Eclipse compile et débugue assez rapidiment: tout se fait dans la MÊME JVM.
Avec GCJ, on élimine un des trois éléments à garder en mémoire: les .class. Ce n'est pas négligeable.
En Java, tout accès à un tableau est soumis à un test pour savoir si l'index est dans les limites du tableau, ce qui rajoute une opération par accès par rapport à C ou C++ par défaut.
Ce comportement peut être modifié avec l'opiton -fno-store-check de GCJ, tout comme il existe un patch de GCC (bounds-checking patch) qui permet de vérifier les limites d'un tableau en C ou C++.
Ensuite, en Java, on ne peut pas allouer un tableau dans le stack, il faut absolument passer par le heap, ce qui ralentit l'allocation ainsi que les accès.
Les tableaux en Java sont donc plus lents qu'en C/C++ mais c'est bien connu et le développeur qui veut de la perf les évite. Pour d'autres usages, la vérification des limites est bienvenue car c'est une cause majeure de bugs en C/C++.
C'est idiot de parler d'erreur de conception ici, Java se veut plus "sûr", donc c'est plus lent, puisque il y a plus d'opérations à exécuter. C'est mieux que de se retrouver dans une zone mémoire indéfinie et de faire exploser son système.
Et C#, il ne vérifie pas les limites des tableaux?
Attention, pas tout mélanger: ce que l'on ne peut pas faire c'est REDISTRIBUER un build fe firefox que l'on aurait fait soi-même et incluant le "branding". Pour une utilisation perso, rien n'est défendu, tu peux l'appeler comme tu veux et utiliser les icônes que tu veux.
D'ailleurs le script configure du source a une option --enable-branding et explique la politique à respecter dans ce cas. Pareil si tu es en entreprise et que tu compile toi-même pour tes utilisateurs, tu peux utiliser le "branding".
Tout cela sert à éviter un fork commercial en se servant de leur marques ou logos bien connus désormais. Simple protection, rien qui ne gène l'utilisateur final.
Pas d'inquiétude donc, juste une défense commerciale.
Pas totalement d'accord avec ton post, la moindre des choses c'est de donner le choix aux clients. Tu veux Windows? lequel? C'est autant. Tu veux Linux, lequel? C'est autant...
HP a tout à fait la possibilité de faire une telle offre, ils le font déjà avec des desktops, du moins ici en GB, tu peux acheter un PC HP avec Mandrake préinstallé et SANS Windows, ce sont d'ailleurs les machines les moins chères de la gamme HP (269 contre 289 livres) http://h10010.www1.hp.com/wwpc/uk/en/sm/WF05a/35123-968421-968421-9(...)
Pareil pour leur gamme "thin client" à base de transmeta, avec Linux -> moins cher, avec XP embedded ajouter £30.
Les faits sont là: chez HP, une machine avec Linux est vendue moins cher que la meme machine avec Windows (chez HP aussi) alors pourquoi ils ne donnent pas le choix pour leurs portables? C'est surement une idée d'un marketeux qui croit donner de la valeur ajoutée à un produit avec le dual boot alors que la valeur ajoutée serait un support complet de Linux sur leur matos.
Ma conclusion, chez HP, c'est des cons mais de moins en moins... En attendant encore un peu, on aura Linux préinstallé sur toute la gamme HP, il reste plus que les portables et les PDA. Patience.
>> Surtout je ne sais pas comment GCJ gerre les dépendance au jar java ?
Ouais, ben il faut se renseigner. L'objectif de GCJ , c'est de remplacer la jvm - complètement. En conservant la compatibilité des applications compilées en bytecode.
Exemple simple: tomcat. Distribué en binaire avec Fedora Core 2, peut charger des .war compilés en bytecode et les faire touner. L'utilisateur ne voit pas de différence.
Les dépendances? Si c'est du binaire, c'est comme en C/C++/Ada avec GCC, ça dépend de s bibliothèques au moment de la compilation et du loader. Si c'est du bytecode, c'est le CLASSPATH en plus du bootclasspath (défini lors de l'installation de GCC)
De plus il y a même un petit projet qui vise à créer une arborescence similaire à un JRE classique à partir des fichiers de gcj, grâce à un système de symlinks, rendant ainsi gcj utilisable par un soft qui requiert cette arborescence pour détecter une "JVM", notamment Openoffice.org et Eclipse.
Dernièrement, avec la version de GCJ qui va sortir avec GCC 4, on pourra charger des classes compilées en natif pendant que le programme tourne, comme avec dlopen(), et le dictionnaire de ces classes sera dispo pour introspection, comme avec des classes bytecode.
[^] # Re: Montgolfière
Posté par k. stephane . En réponse à la dépêche La version 7 de Fedora est sortie !. Évalué à 1.
Bittorrent?
http://torrent.fedoraproject.org/
# On y va! 10000 utilisateurs.
Posté par k. stephane . En réponse à la dépêche Sortie de la version 2.1 de Kolab Groupware Server. Évalué à 7.
On pense pouvoir rouler dans moins de six mois. 10000 utilisateurs et intégration avec notre LDAP en Fedora Directory Server, nous avons financé le connecteur Kolab <-> FDS (c'est dans la release).
Je repasserai avec retour d'expérience, mais je suis très confiant, je voulais du libre et du costaud, et c'est la seule solution viable qui assure.
Faut pas croire que c'est gratuit cependant, comme toute grosse organisation, nous devons avoir un contrat de "support", qui ne sert à rien mais qui est obligatoire et on parle de 50k £ / an, ce qui est bien moins que pour Exchange mais pas donné quand même.
Allez Kolab!
S.
[^] # Re: Coïncidence ?
Posté par k. stephane . En réponse à la dépêche Hula devient un projet communautaire. Évalué à 1.
Ici, on va migrer tout notre mail (4000 utilisateurs) en Kolab, après test, c'est ce qu'il y a de mieux. À voir.
# Passez à Fedora
Posté par k. stephane . En réponse à la dépêche Mandriva 2007 Release Candidate. Évalué à -3.
- Firefox me fait passer par le club pour installer Flash, je suis pas membre, ca marche pas, voilà bien un patch à la con.
- les RPMS sont incompatibles, même les src de Mandriva ne compilent pas avec Fedora, les fichiers .spec ont une syntaxe différente! Bien malin ca aussi.
- les paquets x86_64 ont des noms bizarres: lib64... pourquoi n'avoir pas suivi Fedora pour ca non plus?
- Mandriva libre ? Moins que Fedora.
Et laissez Red Hat en dehors de tout ca s'il vous plaît, Fedora, c'est la première distro totalement communautaire qui marche vraiment du tonnerre, on ne doit pas attendre la nouvelle version de la DISTRO pour avoir la nouvelle version d'un PROGRAMME.
Moi, j'utilise plus que ca, et bientôt je vais la mettre sur des serveurs de prod (<perso>parce que la version de Zope est récente</perso>), en dépit de la garantie "support" de Dell qui impose une RHEL.
J'aimais bien urpmi, mais yum, c'est pas mal non plus faut dire.
Mais ce que j'aime avant tout, c'est l'aspect vraiment libre du projet: pas de softs non libres (poussé à l'extrême, cf le mp3) et une gestion totalement communautaire (avec RedHat derrière mais très effacé). La réactivité est au rendez-vous. C'est toujours plus facile de compiler des softs beta sur Fedora que sur Mandriva, pas besoin de passer par le cooker pour compiler AIGLX, toutes les bibliothèques de dev sont là, par ex.
Pourquoi Mandriva ne reprendrait-elle pas Fedora Core pour la cuisiner à sa sauce et vendre du support orienté bureau, comme le fait Yellow Dog. Tout le monde y gagnerait: avoir un "Core" commun et réactif et ensuite faire du business autour de ce core. Pourquoi donc?
[^] # Re: Serveur avant tout
Posté par k. stephane . En réponse à la dépêche Agenda partagé : des solutions. Évalué à 2.
J'ai essayé sur trois machines, si ca marchait du premier coup, bon, sinon, j'ai eu beau désinstaller et réessayer, pas moyen. C'est comme si il avait pollué le registre une fois et qu'il ne nettoyait rien.
J'ai pas réussi à faire deux bonnes installs d'un coup, alors j'ai abandonné.
En plus, le connecteur Outlook ne se connecte pas au serveur Opengroupware, il se connecte au serveur Skyrix, qui doit être installé aussi en parallèle sur la même machine et se sert des mêmes données et fichiers de configuration que la version libre qui ne sert plus qu'à l'interface web et au "GroupDAV". Pas super propre tout ca.
# Serveur avant tout
Posté par k. stephane . En réponse à la dépêche Agenda partagé : des solutions. Évalué à 3.
Chez nous (10 000 utilisateurs), on n'utilise que du Unix en serveur. Nous sommes tous allergiques à Windows alors nous avons un Samba pour l'authentification et les fichiers. L'email est en IMAP et nous ne proposons pas de solution calendrier, sinon celle de SunONE qui est pourrie et propriétaire.
C'était ma mission de tester des systèmes groupware libres et de voir leur capacité d'intégration et de modification à notre sauce pour remplacer notre SunONE tout fermé.
Et bien, j'ai encore rien trouvé mais je me suis lancé sur OpenGroupware et j'ai fait un thème maison. J'ai aussi essayé le connecteur outlook (propriétaire et payant) qui marche vraiment pas bien. En plus le code est en Objective C et les templates HTML sont partie template, partie généré, sans séparation claire.
Avant ca, j'avais essayé OpenXchange, imbuvable, l'install ressemble à un parcours du combattant et le code ne ressemble à rien. Au moins OpenGroupware proposait des rpms et s'installait tout seul.
C'est du passé de toute facon car depuis que je suis passé à Fedora Core 5 sur le serveur de dev, Opengroupware ne marche plus, son "module" apache étant incompatible avec Apache 2.2... Je pense laisser tomber et je vais me rabbatre sur Kolab en espérant que ca marche.
Chez nous, on ne veut pas forcer les utilisateurs à utiliser tel ou tel programme, ils veulent Outlook, ils l'auront. De plus il faudrait une interface web, que nous pouvons modifier et intégrer dans notre intranet. C'est pour ca qu'on veut de l'open source.
Jusqu'ici, rien, et les solutions ex-propriétaires n'en sont vraiment pas, en tout cas pas pour mon cahier de charges. Peut-être iCal server?
Bien à vous,
Stephane
# codecs propriétaires et streaming mms?
Posté par k. stephane . En réponse à la dépêche GeeXboX Open Media Center: 1.0. Évalué à 1.
Et le mms? Je regarde beaucoup la bbc en ligne et ils streament en real et en windows media.
J'ai bien envie de tester ca sur un vieux portable!
[^] # Re: C'est bien, mais ... -> WorldWind
Posté par k. stephane . En réponse à la dépêche Le nouveau Google Earth arrive... et en version Linux !. Évalué à 4.
[^] # Re: C'est bien, mais ... -> WorldWind
Posté par k. stephane . En réponse à la dépêche Le nouveau Google Earth arrive... et en version Linux !. Évalué à 5.
Je m'en vais l'essayer de ce pas.
[^] # Re: GStreamer et DRM
Posté par k. stephane . En réponse à la dépêche Sortie de GNOME 2.14. Évalué à 2.
La réponse est simple: liberté de choix, tu pourras utiliser les plug-ins Fluendo ou non, en passant par PLF ou Livna. (Il y a déjà un autre plug-in mp3 pour GStreamer)
Il faut malheureusement respecter les règles pour pouvoir distribuer certains programmes soumis à des licences, notamment aux États-Unis. C'est pourquoi pour l'instant, Fedora et Red Hat EL sont livrées sans décodeur mp3. Il est interdit de livrer un décodeur mp3 aux E.U. sans payer une licence à Thomson (bien qu'ils ferment les yeux sur les FLOSS en général).
Avec le plug-in mp3 de Fluendo, Fedora pourra finalement contenir un décodeur mp3. Le plug-in licencié est binaire mais le code est disponible sous licence MIT.
Il en vaut de même pour tous les codecs soumis à brevets ou licence. En gros, en Europe, nous on s'en fout mais les distributeurs seront heureux de pouvoir proposer ces fonctionnalités "out of the box".
Ca protège les distributeurs et ca n'affecte pas l'utilisateur final. Où est le problème?
L'aspect négatif, c'est que on poussera moins l'utilisation de codecs libres comme Vorbis ou Theora, puisqu'on pourra lire des WMA et des AAC.
[^] # Re: Plus besoin de Microsoft en Entreprise!
Posté par k. stephane . En réponse à la dépêche Annonce de Samba 4 Technology Preview. Évalué à 3.
pGina ne comporte pas d'aurtes avantages sur une solution winlogon NT4 basee sur Samba que la customisation. Nous avons trouve cela inutile, puisqu'il nous est plus facile de travailler cote serveur, scripts, backend LDAP...
De plus pGina ne supporte pas (officiellement) Kerberos donc franchement je n'en vois pas l'utilite car si on a du Windows dans son organisation on a forcement un serveur Samba pour les fichiers et l'impression. Ce serveur peut aussi fonctionner comme un serveur d'authentification donc meme resultat avec moins de boulot et pas de changement cote client.
L'avantage de AD sur NT4 c'est l'implementation de Kerberos, c'est ca qui est important. Et Samba 4 implemente cela. Donc encore une fois: pas de changement cote client et administration serveur facile pour des unixiens.
Il existe bien Kerberos for Windows du MIT mais les applications Microsoft (dont IE et Outlook) ne permettent pas d'utiliser une autre bibliotheque kerberos que celle du systeme. Ca marche avec Eudora et Firefox mais comment dire a notre departement cravattes costumes de finances qu'on ne supporte pas Outlook?
Dans mon equipe on fait comme ca et on n'a meme pas un admin Windows!
# Plus besoin de Microsoft en Entreprise!
Posté par k. stephane . En réponse à la dépêche Annonce de Samba 4 Technology Preview. Évalué à 5.
L'utilisation de Samba 3 n'est pas optimale car on n'a pas accès au "Single Sign On" qui a été introduit par Microsoft avec l'utilisation de Kerberos par Windows 2000 Active Directory. L'utilisateur doit cacher ses mots de passe ou les re-taper.
Et non, il n'y a pas plusieurs façons de s'authentifier sous Windows, soit on a les utilisateurs listés en local, soit on fait partie d'un "domaine" Windows (soit on utilise une solution propriétaire bien chère). Le local, quand on a plusieurs milliers d'utilisateurs, c'est impensable. Et unse solution propriétaire, c'est se lier les mains.
Chez nous (plus de 6000 utilisateurs), on est en tout Unix (Linux et Solaris) pour les serveurs et on ne veut pas de Microsoft, résultat, on est obligés de rester en NT4 avec tout les problèmes que cela implique. On voulait passer à Kerberos pour avoir le Single Sign On et la seule solution, c'est de mettre un serveur AD dans notre parc. Pas bon ça. Par principe, dans les faits, ce serveur ne serait qu'une copie de notre Fedora Directory LDAP et l'authentification se ferait par un Kerberos KDC MIT.
Tout cela aurait été plus simple si MS avait implémenté Kerberos à la lettre (sans ajouter ses petites features non-documentées) et si le schéma et le protocole LDAP de AD était public...
Cette nouvelle version de Samba va régler mes problèmes de conscience! En plus d'ajouter de la sécurité à notre réseau.
[^] # Re: Situation différente en Grande Bretagne
Posté par k. stephane . En réponse à la dépêche Les collectivités locales européennes veulent plus de libre. Évalué à 1.
Puis yum, c'est ce qu'il y a de plus pratique même sur RHEL.
[^] # Re: réduction des côuts par les licences plutôt que par le personnel
Posté par k. stephane . En réponse à la dépêche Les collectivités locales européennes veulent plus de libre. Évalué à 4.
Open Exchange est loin d'être un vrai projet Open Source et il faut se lever tôt pour l'installer. Quant à Samba, je ne suis pas un expert mais ça a l'air moins simple que NFS faut avouer.
[^] # Re: Situation différente en Grande Bretagne
Posté par k. stephane . En réponse à la dépêche Les collectivités locales européennes veulent plus de libre. Évalué à -1.
# Situation différente en Grande Bretagne
Posté par k. stephane . En réponse à la dépêche Les collectivités locales européennes veulent plus de libre. Évalué à 5.
C'est dérangeant, je ne sais comment pousser mes utilisateurs à accepter Firefox comme navigateur standard sur les postes. De là à passer en Linux sur poste client, il y a un gouffre.
Ici, tout le monde utilise Windows et a l'impression que c'est ce qui se fait de mieux car ils croient comprendre ce qui s'y passe. Maintenant, ils veulent IE, Outlook et Exchange.
Même chez les admins, mes collègues ont soit un dual boot, soit deux stations. Je ne sais pas ce qu'ils font avec le Windows mais ils s'y connectent fréquemment.
Pareil pour nos serveurs, on a du Solaris et on garde du Solaris. Personne ne parle de migration vers des solutions libres. Même si on doit compiler les logiciels sur Solaris, on les compilera (au lieu de faire "yum install" et bien sûr "yum update"). On a ausi du Sun pour le LDAP et pour le IMAP, pas question de changer. Solaris, c'est bien(TM).
Autant on a l'impression de vivre à la pointe de l'IT ici, autant on perçoit un conservatisme sous-jacent. Je ne sais pas quoi faire pour avancer l'idée d'une migration. Quelqu'un a une idée?
# AMD64?
Posté par k. stephane . En réponse à la dépêche Sortie de la version 0.7.1 de Looking Glass. Évalué à 2.
[^] # Re: Finalement
Posté par k. stephane . En réponse à la dépêche Daniel Robbins rejoint Microsoft. Évalué à 2.
Mmm, il travaille surtout sur Webcore, en LGPL.
Donc je ne suis pas tout à fait d'acord avec ta justification de la nécessité de travailler. Il faut bouffer, oui, mais on peut choisir où on fait ses courses.
Pour ma part, j'ai toujours programmé avec du libre -- des logiciels à usage interne ou sur commande (ce qui correspond à plus de 80% du marché du logiciel. Ouais, c'est ça du logiciel, pas ce qui s'achète à la FNAC). Et j'ai toujours programmé et déployé sous des systèmes libres que ce soit du J2EE sous JBOSS ou du C++ avec gcc ou du script des plus variés sous Linux.
Le mec il a choisi d'aller chez crosoft, et la meilleure justification semble le pèze plus qu'autre chose sinon pourquoi aller chez l'ennemi des idées que l'on défendait il y a peu?
Vous savez combien on lui a offert chez crosoft? C'est un salaire annuel à six chiffres?
Pour info, Linus gagne 200k $ / an (lu dans BusinessWeek), alors le gars Robbins il a bien dû se laisser tenter par quelque chose du genre, non?
Ceci dit je n'ai aucune preuve de ce que j'avance et peut-êtr bien qu'il part chez crosoft comme un évangélisateur, j'en doute...
[^] # Re: du déjà vu
Posté par k. stephane . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. Évalué à 10.
Ce qui signifie que l'on n'a pas besoin des sources de la librairie à analyser, on n'utilise que des appels GObject.
Glade fonctionne d'ailleurs comme ça. Il fouille les objets de Gtk+ pour en extraire les propriétés et les signaux et ensuite permettre leur modification via sa GUI. C'est bien plus que simplement trouver les méthodes et les champs publics. GObject, c'est JavaBeans aux stéroïdes.
De plus GObject permet aux bindings d'étendre les types GObject et aussi de passer des fonctions dans leur langage aux signaux. Ça va très loin. La création de bindings automatique n'est q'une utilisation de cette introspection, Glade en est une autre et qui sait, un IDE pour GObject...?
[^] # Re: 2 question bete a propos du java
Posté par k. stephane . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
Le problème de GCJ, c'est les bibliothèques, pas la compilation, ça c'est au point.
Tu peux même compiler directement un .jar: gcj -shared my.jar -o lib-my.so, et la JRE de GCJ peut même charger ton .jar compilé au runtime avec Class.forName(), il y a une convention à respecter pour le nom de la lib et il faut que la lib soit dans le $LD_LIBRARY_PATH
Donc oui, théoriquement, tu peux prendre un programme Java Bytecode et le compiler en natif pour une plateforme supportée par GCJ et pour laquelle il n'y a pas de JVM proprio dispo, comme Linux PPC par exemple... Mais il faut que ce programme soit "pur" Java (pas de code natif JNI) et n'utilise que ce qui est supporté par Classpath. Tu peux alors avoir Tomcat sur Linux PPC, par exemple.
Attention cependant: GCJ ne supporte pas toutes les architectures de la même façon et en supporte moins que GCC.
[^] # Re: Nécessité de Java?
Posté par k. stephane . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
Les classes sont chargées en mémoire puisqu'il s'agit d'un interpréteur. Et en plus, lorsque la JVM précompile certaines parties de code (avec le JIT), elle les cache en mémoire aussi.
Donc, on garde en mémoire les classes (.class) -- même celles qu'on n'utilise pas car les .jar sont chargés en entier (pas sûr)--, les dictionnaires (méta-données) des classes (nom de classe, des méthodes, des champs + accès), les bouts de code précompilés. C'est lourd tout ça... Mais il n'y a que la mémoire qui soit affectée, pas les perfs. Et tout se situe au niveau de la JVM, c'est pour ça que Eclipse compile et débugue assez rapidiment: tout se fait dans la MÊME JVM.
Avec GCJ, on élimine un des trois éléments à garder en mémoire: les .class. Ce n'est pas négligeable.
[^] # Re: Nécessité de Java?
Posté par k. stephane . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 1.
Ce comportement peut être modifié avec l'opiton -fno-store-check de GCJ, tout comme il existe un patch de GCC (bounds-checking patch) qui permet de vérifier les limites d'un tableau en C ou C++.
Ensuite, en Java, on ne peut pas allouer un tableau dans le stack, il faut absolument passer par le heap, ce qui ralentit l'allocation ainsi que les accès.
Les tableaux en Java sont donc plus lents qu'en C/C++ mais c'est bien connu et le développeur qui veut de la perf les évite. Pour d'autres usages, la vérification des limites est bienvenue car c'est une cause majeure de bugs en C/C++.
C'est idiot de parler d'erreur de conception ici, Java se veut plus "sûr", donc c'est plus lent, puisque il y a plus d'opérations à exécuter. C'est mieux que de se retrouver dans une zone mémoire indéfinie et de faire exploser son système.
Et C#, il ne vérifie pas les limites des tableaux?
[^] # Re: Ça va devenir compliqué!
Posté par k. stephane . En réponse à la dépêche Mozilla définit la politique d'utilisation de ses marques.. Évalué à 6.
D'ailleurs le script configure du source a une option --enable-branding et explique la politique à respecter dans ce cas. Pareil si tu es en entreprise et que tu compile toi-même pour tes utilisateurs, tu peux utiliser le "branding".
Tout cela sert à éviter un fork commercial en se servant de leur marques ou logos bien connus désormais. Simple protection, rien qui ne gène l'utilisateur final.
Pas d'inquiétude donc, juste une défense commerciale.
Stéphane
[^] # Re: une telle offre est déjà une bonne chose pour linux...
Posté par k. stephane . En réponse à la dépêche Mobilisation pour le portable HP-Compaq sans Windows sur le Mandrakestore. Évalué à 3.
HP a tout à fait la possibilité de faire une telle offre, ils le font déjà avec des desktops, du moins ici en GB, tu peux acheter un PC HP avec Mandrake préinstallé et SANS Windows, ce sont d'ailleurs les machines les moins chères de la gamme HP (269 contre 289 livres) http://h10010.www1.hp.com/wwpc/uk/en/sm/WF05a/35123-968421-968421-9(...)
Pareil pour leur gamme "thin client" à base de transmeta, avec Linux -> moins cher, avec XP embedded ajouter £30.
Les faits sont là: chez HP, une machine avec Linux est vendue moins cher que la meme machine avec Windows (chez HP aussi) alors pourquoi ils ne donnent pas le choix pour leurs portables? C'est surement une idée d'un marketeux qui croit donner de la valeur ajoutée à un produit avec le dual boot alors que la valeur ajoutée serait un support complet de Linux sur leur matos.
Ma conclusion, chez HP, c'est des cons mais de moins en moins... En attendant encore un peu, on aura Linux préinstallé sur toute la gamme HP, il reste plus que les portables et les PDA. Patience.
[^] # Re: Quelques questions d'avenir...
Posté par k. stephane . En réponse à la dépêche Solaris officiellement annoncé sous licence Open Source. Évalué à 4.
Ouais, ben il faut se renseigner. L'objectif de GCJ , c'est de remplacer la jvm - complètement. En conservant la compatibilité des applications compilées en bytecode.
Exemple simple: tomcat. Distribué en binaire avec Fedora Core 2, peut charger des .war compilés en bytecode et les faire touner. L'utilisateur ne voit pas de différence.
Les dépendances? Si c'est du binaire, c'est comme en C/C++/Ada avec GCC, ça dépend de s bibliothèques au moment de la compilation et du loader. Si c'est du bytecode, c'est le CLASSPATH en plus du bootclasspath (défini lors de l'installation de GCC)
De plus il y a même un petit projet qui vise à créer une arborescence similaire à un JRE classique à partir des fichiers de gcj, grâce à un système de symlinks, rendant ainsi gcj utilisable par un soft qui requiert cette arborescence pour détecter une "JVM", notamment Openoffice.org et Eclipse.
Dernièrement, avec la version de GCJ qui va sortir avec GCC 4, on pourra charger des classes compilées en natif pendant que le programme tourne, comme avec dlopen(), et le dictionnaire de ces classes sera dispo pour introspection, comme avec des classes bytecode.
GCJ, ça ROXOR! Merci RedHat
Stephane