Resin, de Caucho ( http://www.caucho.com/ ), est également une excellent conteneur de Servlet à la "mode" Jetty (par "mode", j'entends conteneur léger capable d'être étendu pour se rapprocher du monde JEE).
Mais entre ces micro-conteneurs qui peuvent grossir selon les besoins et les serveur applicatifs full-JEE qui s'allègent et se modularisent (voir Glassfish v3, une merveille) j'ai comme l'impression que l'on s'oriente lentement mais surement vers une convergence fonctionnelle. :)
Le concept est intéressant, mais inapplicable quand les charges fixes sont importantes (essentiellement le loyer). Parce que la pépinière a une fonction plutôt d'intérêt public, nous comptons essayer d'obtenir des subventions pour couvrir ces frais. A ce moment là, le prix libre devient possible :)
Je vais mettre à jour le site en fonction de vos remarques. dans les prochains jours.
Effectivement, les services offerts vont au delà d'un centre d'affaires :
- aide à la création de l'entreprise: choix de la forme juridique, des différentes options d'impositions et de taxation
- aide à la mise en place du dispositif spécifique à la ZFU
- aide à l'insertion dans le tissu économique local : présentations des groupes et associations pertinentes; relai d'informations sur les formations gratuites des organismes publics; incitation à la réponse d'appels d'offres en commun (X développe, Y forme, Z assure la maintenance serveur par exemple)...
- suivi des performances
A noter qu'il n'y a pas de service d'expert comptable (ce qui, dans les faits, est rarement un des services offerts du moins sur les pépinière de Toulouse que je connais), mais nous comptons pouvoir négocier des tarifs avantageux par un effet "de groupe".
Ce qui est important de comprendre, c'est que l'esprit est voulu très participatif, et que ce n'est pas la pépinière qui accueille une nouvelle entreprise, mais tous ses occupants. Peut être que parler d'une Communauté d'Entreprises du Logiciel Libre est plus approprié.
64 bytes from prout.linuxfr.org (88.191.250.104): icmp_seq=1 ttl=58 time=0.713 ms
64 bytes from prout.linuxfr.org (88.191.250.104): icmp_seq=2 ttl=58 time=0.754 ms
64 bytes from prout.linuxfr.org (88.191.250.104): icmp_seq=3 ttl=58 time=0.691 ms
64 bytes from prout.linuxfr.org (88.191.250.104): icmp_seq=4 ttl=58 time=0.749 ms
Mmmmmm les joies du p'tit serveur dédié chez OVH :-)
Il existe un exemple simple pour le module de compta, dans une cadre législatif français ? Genre je configure la TVA, j'entre deux/trois services, je fais une devis, je facture, je marque les trois paiements de ladite facture, je clôt la facture, et j'enregistre une facture fournisseur ?
Ha moi perso j'en mets zéro parce que je ne joue pas avec ça, j'utilise juste ESXi pour consolider des serveurs Linux (Xen est à mon goût pas encore assez "fini").
C'est une architecture gourmande en RAM, mais très peu en disque : il est possible d'avoir une image "template", et pour chaque machine virtuelle d'utilisateur, on ne stocke que le delta. La place gagnée est énorme, et ça, ça permet d'économiser un tas de $$$ en backup, stockage, etc etc. En plus, en modifiant le "template", on mets à jour toutes les machines utilisateurs. Dans les détails, je ne sais pas comment c'est implémenté, mais je suppose que ça ne fonctionne qu'avec certains OS comme Windows (snif).
Je ne connais pas de solutions libres comparables à VMware View. Le plus proche est XenDesktop, qui se base sur du libre mais avec du proprio dedans et qui a une propriété intéressante: le desktop virtualisé peut être exécuté sur un hyperviseur ... en local (l'image disque étant sur le réseau, pour simplifier). Si quelqu'un connait un équivalent libre stable, je suis preneur!
La gestion des ressources partagées et locale est prise en compte dans la plupart des solutions, c'est le minimum pour être "sérieux".
VMware View est une solution "au dessus" de VMware infrastructure (la solution de virtualisation de VMware) pour virtualiser les postes de travail. Contrairement à du X11/NX/Terminal Server/... (un serveur pour plein d'utilisateurs), chaque utilisateur a sa propre machine virtuelle sur le serveur.
Jusqu'à présent, pour obtenir une console "graphique" sur son poste de travail virtualisé, il fallait soit utiliser le client (VMware View Open Client, open source à présent, "Windows only" avant), soir utiliser un terminal léger compatible (certains terminaux HP, notamment).
Diantre, mais pourquoi ne pas plutôt prendre une seule grosse machine virtuelle X11/Terminal Server et rester sur un modèle centralisé plus simple à administrer, me diriez-vous (non ?). Parce qu'avec un poste de travail virtualisé par utilisateur, il est bien plus facile de faire des choses rigolotes qu'aiment les grosses entreprise: haute disponibilité et surtout la -> répartition de charge automatique <- (pour quelques grosses dizaines de milliers d'euros de licence chez VMware).
Tout ça c'est bien mignon quand on a donc plusieurs serveurs sous VMware infrastructure. Sinon, ben le "modèle un gros serveur applicatif pour tlm" est bien plus approprié la plupart du temps (avec un p'tit Xen ou ESXi, la solution de virtualisation pas libre mais gratuite de VMware qui est sympa si on reste sur un seul serveur).
> VMware, leader des solutions de virtualisation, a annoncé la mise à disposition des sources de sa nouvelle solution libre de virtualisation
Le premier paragraphe est erroné. Le code source d'un client VmWare View n'est pas une "solution libre de virtualisation". Xen, c'est une solution libre de virtualisation. VirtualBox, aussi. Mais "VMware View Open Client" ne l'est pas. Les autres paragraphes sont Ok.
Contrairement à ce que pourrait laisser croire la dépêche, VmWare a passé sous licence libre que l'outil CLIENT qui permet de se connecter à VmWare View (une solution de virtualisation des desktop).
Les solutions de virtualisation de VmWare restent propriétaires.
Ce qui était compliqué dans l'ancienne doc, c'est de ne pas avoir bien séparé les procédures selon les distributions ET les releases des distributions (par séparé, j'entends une page spécifique à chaque release comprenant l'intégralité de la procédure adaptée). Du coup, maintenant, par exemple si on veut la doc pour une install sur Ubuntu (do not feed the troll ;) avec les paquets (chacun ses contraintes!) il va falloir chercher la doc appropriée ailleurs. Dommage, mais rien de rédhibitoire :)
La "nouvelle" doc ne mentionne plus les procédures d'install avec les paquets Debian. Dois-je en conclure que c'est parce que les paquets ne sont pas encore prêts ou que c'est maintenant déconseillé et qu'il vaut mieux passer par les sources et tout le toin toin (et adieu l'intégration à init; enfin bonjour vi pour le faire à la mano) ?
Il me tarde de voir ce que la nouvelle monture a dans le ventre :)
Il y a de la doc quelque part pour attaquer Alfresco via CMIS en Atom ? Par doc, je ne veux pas dire des specs obtues (j'ai commencé à lire 'CMIS Part II -- REST-Atom Binding v0.5'), mais des exemples simples et documentés de sessions HTTP (ou au pire, du code PHP crade mais facile à comprendre)
J'ai bien envie d'écrire une librairie C++/Qt pour pouvoir intégrer une application de lecture automatique de documents (LAD).
Heureusement, il reste de bon vieux trolls bien poilus et indestructible.
Vi rules, Emacs sucks!
A vous :D
Plus sérieusement, ce passage sous LGPL est une bénédiction pour les microISV/startups qui ne peuvent se payer la licence pour chaque développeur, même si ladite licence n'est pas si chère comparée au gain de productivité obtenu avec Qt.
De mémoire, pour ZFS, le Copy On Write (COW) se fait au niveau bloc, donc seuls les blocs modifiés sont dupliqués. Donc oui, en cas de gros fichiers faiblement modifiés, c'est 'efficient'.
Excellent journal, qui bien qu'ironique n'est pas si loin de la réalité telle qu'elle a été il y a quelques années.
Heureusement, depuis, les choses ont évolué et beaucoup de ces pseudo-consultant virés depuis sont revenus par une autre porte, convertis à des technicobuzz plus récents (méthodes Agiles, par exemple : rien de mauvais en soi mais si mal "consulté"...). Et la technologie aussi, elle, a évolué, un peu, quoi, si...
Tiens, je devrais écrire une parodie "mise à jour" sur J2EE :)
Oui, je le crois. Allez, trollons, en janvier, c'est autorisé :-)
Pourquoi J2EE sans masochiste? Par ce que c'est excellemment outillé, bien documenté, parce qu'il y a toujours une librairie de qualité pour répondre à un besoin, parce que depuis J2EE 1.6 c'est quand même beaucoup moins lourd (annotations, JPA, etc etc).
Oui, il n'y a pas le côté "fun" d'un Python 3K ou d'un Ror et il faut quand même encore écrire deux fois plus de ligne de code en Java pour obtenir un programme bien plus gourmand en RAM, mais au final, ce qui compte, c'est que ça marche, et bien (en particulier le clustering, ça a un côté magique). Plus chiant mais résultats prévisibles et stables sans perdre des jours entier à bidouiller pour contourner un obscure fonction non documentée, en résumé :-)
Pour infos, j'ai créé ma boite et au début, Java/J2EE, je ne pouvais pas le sentir. Mais à force de constater que "tiens, pour l'indexation, avec Lucene ça serait tellement mieux", "tiens, pour le déploiement JWS c'est quand même top"... ben au final, j'y suis passé. Et maintenant j'apprécie même certains points, comme les EJB stateless et remote.
Je vais me faire moisser, mois :-D Allez, encore un "vive J2EE" pour la route.
Plus sérieusement, avec la montée (lente mais réelle) en popularité de GlassFish, il va bien finir par avoir une armée de libristes J2EEiens. Par des architectes hautains mais des bon p'tits programmeurs qui tournent à la bière, la pizza et au résultat.
Techniquement Java (enfin, J2EE) est une excellente solution technique (surtout pour encaisser le traffic conséquent de Linuxfr.org) et en plus on peut faire du 100% libre (OpenJDK, GlassFish, ...).
Mais c'est hélas un choix qui serait loin d'emporter le consensus :-( Le plus (?) important, c'est d'avoir une communauté: des contributeurs, des victimes testeurs...
# il ne faut passe resin-ner
Posté par Arnaud . En réponse au journal Jetty mais costaud. Évalué à 2.
Mais entre ces micro-conteneurs qui peuvent grossir selon les besoins et les serveur applicatifs full-JEE qui s'allègent et se modularisent (voir Glassfish v3, une merveille) j'ai comme l'impression que l'on s'oriente lentement mais surement vers une convergence fonctionnelle. :)
[^] # Re: Prix libre
Posté par Arnaud . En réponse au journal Création de Graine Libre, pépinière d'entreprise spécialisée dans le Logiciel Libre. Évalué à 3.
[^] # Re: pepiniere ou housing ?
Posté par Arnaud . En réponse au journal Création de Graine Libre, pépinière d'entreprise spécialisée dans le Logiciel Libre. Évalué à 3.
Effectivement, les services offerts vont au delà d'un centre d'affaires :
- aide à la création de l'entreprise: choix de la forme juridique, des différentes options d'impositions et de taxation
- aide à la mise en place du dispositif spécifique à la ZFU
- aide à l'insertion dans le tissu économique local : présentations des groupes et associations pertinentes; relai d'informations sur les formations gratuites des organismes publics; incitation à la réponse d'appels d'offres en commun (X développe, Y forme, Z assure la maintenance serveur par exemple)...
- suivi des performances
A noter qu'il n'y a pas de service d'expert comptable (ce qui, dans les faits, est rarement un des services offerts du moins sur les pépinière de Toulouse que je connais), mais nous comptons pouvoir négocier des tarifs avantageux par un effet "de groupe".
Ce qui est important de comprendre, c'est que l'esprit est voulu très participatif, et que ce n'est pas la pépinière qui accueille une nouvelle entreprise, mais tous ses occupants. Peut être que parler d'une Communauté d'Entreprises du Logiciel Libre est plus approprié.
[^] # Re: moins de 5ms
Posté par Arnaud . En réponse au sondage ping linuxfr.org me donne. Évalué à 2.
# moins de 5ms
Posté par Arnaud . En réponse au sondage ping linuxfr.org me donne. Évalué à 1.
64 bytes from prout.linuxfr.org (88.191.250.104): icmp_seq=2 ttl=58 time=0.754 ms
64 bytes from prout.linuxfr.org (88.191.250.104): icmp_seq=3 ttl=58 time=0.691 ms
64 bytes from prout.linuxfr.org (88.191.250.104): icmp_seq=4 ttl=58 time=0.749 ms
Mmmmmm les joies du p'tit serveur dédié chez OVH :-)
# Exemple pour la compta
Posté par Arnaud . En réponse à la dépêche OpenERP 5.0. Évalué à 2.
Ou un bon bouquin qui explique bien cela ??
[^] # Re: Pas trop saisi
Posté par Arnaud . En réponse à la dépêche VMware View Open Client passe sous LGPL. Évalué à 4.
C'est une architecture gourmande en RAM, mais très peu en disque : il est possible d'avoir une image "template", et pour chaque machine virtuelle d'utilisateur, on ne stocke que le delta. La place gagnée est énorme, et ça, ça permet d'économiser un tas de $$$ en backup, stockage, etc etc. En plus, en modifiant le "template", on mets à jour toutes les machines utilisateurs. Dans les détails, je ne sais pas comment c'est implémenté, mais je suppose que ça ne fonctionne qu'avec certains OS comme Windows (snif).
Je ne connais pas de solutions libres comparables à VMware View. Le plus proche est XenDesktop, qui se base sur du libre mais avec du proprio dedans et qui a une propriété intéressante: le desktop virtualisé peut être exécuté sur un hyperviseur ... en local (l'image disque étant sur le réseau, pour simplifier). Si quelqu'un connait un équivalent libre stable, je suis preneur!
La gestion des ressources partagées et locale est prise en compte dans la plupart des solutions, c'est le minimum pour être "sérieux".
[^] # Re: Pas trop saisi
Posté par Arnaud . En réponse à la dépêche VMware View Open Client passe sous LGPL. Évalué à 3.
Jusqu'à présent, pour obtenir une console "graphique" sur son poste de travail virtualisé, il fallait soit utiliser le client (VMware View Open Client, open source à présent, "Windows only" avant), soir utiliser un terminal léger compatible (certains terminaux HP, notamment).
Diantre, mais pourquoi ne pas plutôt prendre une seule grosse machine virtuelle X11/Terminal Server et rester sur un modèle centralisé plus simple à administrer, me diriez-vous (non ?). Parce qu'avec un poste de travail virtualisé par utilisateur, il est bien plus facile de faire des choses rigolotes qu'aiment les grosses entreprise: haute disponibilité et surtout la -> répartition de charge automatique <- (pour quelques grosses dizaines de milliers d'euros de licence chez VMware).
Tout ça c'est bien mignon quand on a donc plusieurs serveurs sous VMware infrastructure. Sinon, ben le "modèle un gros serveur applicatif pour tlm" est bien plus approprié la plupart du temps (avec un p'tit Xen ou ESXi, la solution de virtualisation pas libre mais gratuite de VMware qui est sympa si on reste sur un seul serveur).
[^] # Re: Houlalala
Posté par Arnaud . En réponse à la dépêche VMware View Open Client passe sous LGPL. Évalué à 10.
> VMware, leader des solutions de virtualisation, a annoncé la mise à disposition des sources de sa nouvelle solution libre de virtualisation
Le premier paragraphe est erroné. Le code source d'un client VmWare View n'est pas une "solution libre de virtualisation". Xen, c'est une solution libre de virtualisation. VirtualBox, aussi. Mais "VMware View Open Client" ne l'est pas. Les autres paragraphes sont Ok.
# Houlalala
Posté par Arnaud . En réponse à la dépêche VMware View Open Client passe sous LGPL. Évalué à 9.
Les solutions de virtualisation de VmWare restent propriétaires.
[^] # Re: Installation à base de paquets ???
Posté par Arnaud . En réponse à la dépêche OpenERP 5.0. Évalué à 1.
# Installation à base de paquets ???
Posté par Arnaud . En réponse à la dépêche OpenERP 5.0. Évalué à 1.
Il me tarde de voir ce que la nouvelle monture a dans le ventre :)
# Enfin...
Posté par Arnaud . En réponse au journal Debian GNU/Linux 5.0 RC2. Évalué à 9.
# Exemples CMIS
Posté par Arnaud . En réponse à la dépêche Alfresco lance la version 3 finale. Évalué à 3.
J'ai bien envie d'écrire une librairie C++/Qt pour pouvoir intégrer une application de lecture automatique de documents (LAD).
# Ha zut...
Posté par Arnaud . En réponse à la dépêche Qt 4.5 sera sous licence LGPL 2.1. Évalué à 8.
Vi rules, Emacs sucks!
A vous :D
Plus sérieusement, ce passage sous LGPL est une bénédiction pour les microISV/startups qui ne peuvent se payer la licence pour chaque développeur, même si ladite licence n'est pas si chère comparée au gain de productivité obtenu avec Qt.
[^] # Re: Une question bête ...
Posté par Arnaud . En réponse au journal Qt LGPL!. Évalué à 2.
[^] # Re: Granularité du COW ?
Posté par Arnaud . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 4.
Il me semble que c'est aussi le cas pour btrfs, mais je n'ai pas encore bien digéré l'explication du design, à lire pour les mordus de FS: http://btrfs.wiki.kernel.org/index.php/Btrfs_design
[^] # Re: Brainfuck
Posté par Arnaud . En réponse au journal Journal : LinuxFR en whitespace ?. Évalué à 5.
http://xkcd.com/378/
XKCD, j'adore :)
[^] # Re: pas mal !
Posté par Arnaud . En réponse au journal Linuxfr en J2EE. Évalué à 3.
# Mdr
Posté par Arnaud . En réponse au journal Linuxfr en J2EE. Évalué à 4.
Heureusement, depuis, les choses ont évolué et beaucoup de ces pseudo-consultant virés depuis sont revenus par une autre porte, convertis à des technicobuzz plus récents (méthodes Agiles, par exemple : rien de mauvais en soi mais si mal "consulté"...). Et la technologie aussi, elle, a évolué, un peu, quoi, si...
Tiens, je devrais écrire une parodie "mise à jour" sur J2EE :)
[^] # Re: Défi
Posté par Arnaud . En réponse au journal LinuxFR en rails ?. Évalué à 4.
Memcached vs Terracotta, MySql vs PostgreSQL (nooooooo do not feed the troll)
Après, derrière, que ce soit PHP/Django/Ror/J2EE, je doute que les écarts soit si importants si on reste sur un unique serveur Web+DB
[^] # Re: Grillé
Posté par Arnaud . En réponse au journal LinuxFR en rails ?. Évalué à 10.
Pourquoi J2EE sans masochiste? Par ce que c'est excellemment outillé, bien documenté, parce qu'il y a toujours une librairie de qualité pour répondre à un besoin, parce que depuis J2EE 1.6 c'est quand même beaucoup moins lourd (annotations, JPA, etc etc).
Oui, il n'y a pas le côté "fun" d'un Python 3K ou d'un Ror et il faut quand même encore écrire deux fois plus de ligne de code en Java pour obtenir un programme bien plus gourmand en RAM, mais au final, ce qui compte, c'est que ça marche, et bien (en particulier le clustering, ça a un côté magique). Plus chiant mais résultats prévisibles et stables sans perdre des jours entier à bidouiller pour contourner un obscure fonction non documentée, en résumé :-)
Pour infos, j'ai créé ma boite et au début, Java/J2EE, je ne pouvais pas le sentir. Mais à force de constater que "tiens, pour l'indexation, avec Lucene ça serait tellement mieux", "tiens, pour le déploiement JWS c'est quand même top"... ben au final, j'y suis passé. Et maintenant j'apprécie même certains points, comme les EJB stateless et remote.
Je vais me faire moisser, mois :-D Allez, encore un "vive J2EE" pour la route.
---> []
[^] # Re: Grillé
Posté par Arnaud . En réponse au journal LinuxFR en rails ?. Évalué à 2.
Plus sérieusement, avec la montée (lente mais réelle) en popularité de GlassFish, il va bien finir par avoir une armée de libristes J2EEiens. Par des architectes hautains mais des bon p'tits programmeurs qui tournent à la bière, la pizza et au résultat.
[^] # Re: Grillé
Posté par Arnaud . En réponse au journal LinuxFR en rails ?. Évalué à 3.
[^] # Re: Grillé
Posté par Arnaud . En réponse au journal LinuxFR en rails ?. Évalué à 2.
Mais c'est hélas un choix qui serait loin d'emporter le consensus :-( Le plus (?) important, c'est d'avoir une communauté: des contributeurs, des victimes testeurs...