La gestion des affaires récurrentes est à envisager sous forme de module. Pour ce qui est des statistiques par commerciaux, on a pas encore eu le temps de l'intégrer mais on l'a sous le coude.
Je suis preneur en MP de ce que tu lui reproches et de tes attentes.
Nous finalisons la version 1.1 et commençons la roadmap pour la 1.2, c'est donc le bon moment.
Si as en tête le nom d'un profiler C/C++ qui peut rivaliser, n'hésites pas car j'ai du passé à côté. (On ne pas tout connaître et tout tester!)
J'imagine qu'il faudra tout de même recompiler l'appli... non?
Niveau performance, sur de gros programmes, un programmeur Java avec les bons outils de profiling réussira rapidement à avoir un logiciel plus rapide que son équivalent C/C++.
Sur les micro-benchmarks, C et C++ resterons à mon avis toujours meilleurs car les performances découlent d'optimisations liées aux instructions processeurs utilisée.
En revanche, sur un logiciel de plusieurs milliers de lignes (genre au hasard OpenConcerto :) ), en quelques minutes, avec jProfiler par exemple, le coder Java voit exactement:
- où sont les hotspots à optimiser,
- quand les threads sont en attentes,
- ce qui est parallélisable
et tout cela en ayant la hiérarchie des appels, les temps moyens, les nombres d'appels et j'en passe! Beauté de la chose: cela se fait sans recompiler ou modifier quoi que soit à l'application.
Bref, l'outil étonne souvent, les pertes de performances sont rarement là où on les cherche. Ayant passé des heures à optimiser des codes assembleur, C, C++ et Java, je vois en java une excellente plateforme pour atteindre rapidement d'excellentes performance sur des logiciels de taille importante.
Pour tout ceux qui n'aurait pas encore testé un outil comme jProfiler, faites un tour sur jOpenDocument section benchmark. Après quelques heures de profiling, nous avons optimisé la génération de documents OpenDocument: 17 ms pour créer un document (dont 12ms passées dans l'accès disque) quand une autre librairie (ODFDOM) à besoin de 126ms, ça parle tout de suite!
Pour les betas de la version 1.1, il ne faut pas être un hacker mais être assez téméraire pour configurer un serveur PostgreSQL. Le reste est une question de clics.
La betas sont disponibles depuis le forum, il reste encore un peu de travail pour fournir une version installable en 3 clics de la version 1.1 sur toutes les plateformes.
Fort de l'investissement de Jaïna Cpaital d'un montant de 10 millions d'euros annoncé ce jour, OpenConcerto profite de ce grand jour pour dévoiler son premier investissement: 1 million d'euros pour l'intégration de sa suite logiciel de gestion sur la DLFPBox.
Un communiqué de presse complet suivra dans quelques jours.
OpenConcerto est bel et bien un ERP. Je comprend très bien qu'on puisse facilement passer à côté vu que nous avons encore pas mal de doc à écrire :)
Pour la configuration, il ne faut pas mélanger les préférences et la configuration de l'ensemble.
La gestion des droits est là et est très compléte (Menu Structure), il est possible par exemple de gérer indépendament les droits sur chaque action (tables) pour: ajout, modification, suppression et accès en lecture.
Ces droits sont par utilisateur. Les menus se simplifient en fonction des droits associés. Il est possible de gérer les droits par "ensemble".
Il est aussi tout à fait possible de supprimer le module de compta et de modifier les workflow.
Nous avons mis l'accent sur la possibilité de créer des modules pour ajouter des fonctionnalités, changer des comportements, faire des imports, etc...
Encore un peu de patience, nous allons fournir doc et outils. Vous verrez que nous avons un système efficace d'accès aux bases de données et d'UI.
Pour les boîtes de dialogues, est ce que cela touche toutes les fenêtres du logiciel? Peut-on en savoir un peu plus sur votre distribution, version de java, etc?
Le logiciel doit également mémoriser la position des fenêtres, est ce que cela fonctionne?
Que proposez vous pour remplacer le fond jaune clignotant des champs pas ou incorrectement remplis?
Nous avons déjà quelques idées pour construire un modèle économique viable (pour les utilisateurs comme pour nous).
Parmi elles:
vente d'un manuel d'utilisation
commercialisation de services et de support (sur site, par téléphone, emails) via partenaires et en direct
développements spécifiques de modules (fonctionnalités, imports, interfaces à d'autres systèmes...)
formations
fourniture de solutions clef en main (matériel, logiciels, installation et maintenance
En gros, tout ce que nous faisons déjà pour nos clients.
Nous serions très contents d'avoir quelques contributions spontanées (en pub ou en code),
pour cela nous préparons les documentations nécessaires.
Nous pensons aussi à mettre en place un système de mutualisation des financements de développement sur des modules.
En effet, tout le monde n'a pas forcément un budget conséquent pour un logiciel de gestion.
Il n'est pas rare pour nous de voir des clients "subir" un logiciel en boîte qui ne nécessiterait pourtant que quelques modifications pour être éfficace. La politique de l'éditeur étant de faire un logiciel qui peut "convenir" à tous, ça ne risque pas d'arriver...
Un bon argument pour choisir OpenConcerto.
J'imagine aussi que certains acheteurs verront en OpenConcerto une bonne base pour un système informatique
performant et préféreront investir en développement une partie du budget économisé en licence.
Au risque de surprendre, même si OpenConcerto ne rapporte que quelques centimes, nous continuerons à le développer et à le faire vivre en opensource.
Tout simplement car nous avons déjà des clients qui l'utilisent depuis quelques années et qui n'ont pas envie de s'en passer.
Le temps nécessaire à contribuer nos développements dans OpenConcerto est négligeable face à ce qu'un projet opensource nous apporte: visibilité et crédibilité. jOpenDocument a déjà fait beaucoup et au vu des 1400 visites enregistrées par google analytics en 2 jours pour OpenConcerto, nous sommes assez optimistes!
Tout à fait d'accord avec toi, une application en web en local n'a pas de soucis de dépendance du bon fonctionnement de la liaison internet, mais comme je l'indiquais, nous ne somme pas convaincu de la pertinence du "tout navigateur" pour faire une application de gestion en réseau (local).
Un forum, un webmail, un CMS ou un bugtracker c'est très bien dans un navigateur, mais quand il faut commencer à discuter avec une imprimante série, une douchette code à barres et un tiroir caisse... on est bien content d'avoir un peu plus que HTML/CSS/JavaScript.
Pour faire court, disons que développer une application web c'est avant tout se battre contre les limitations des navigateurs, la latence réseau et les débits pas toujours terribles.
Côté "OnCloud", OpenConcerto est techniquement prêt. Base de données sur le cloud et logiciel lancé en utilisant webstart, ca fonctionne très bien sur une liaison 3G.
L'interface graphique du logiciel étant asynchrone, les problèmes liés à la latence et aux débits sont résolus. Nous avons des clients qui utilisent le logiciel à travers des liaisons VPNs en ADSL pour faire du multisite et multisociété et sont ravis de voir que les performances sont là.
Pour donner une idée des limitations que nous ne voulions pas avoir, voici un exemple concret: l'édition de facture.
Imaginons qu'un client ait dans sa "procédure qualité" la contrainte qu'une facture doit être toujours imprimée en 2 exemplaires (une pour la société, une pour le client):
- Un ERP web, proposera un bouton "imprimer" qui créera la facture (souvent en PDF) sur le serveur, l'enverra au navigateur de l'utilisateur, la visionneuse du système prendra le relais pour afficher le document, l'utilisateur cliquera "imprimer", 2 fois. Cela prend plusieurs clics et plusieurs secondes.
- Avec OpenConcerto, le bouton imprimer peut lancer directement l'impression sur l'imprimante en 2 exemplaires sans rien demander à l'utilisateur. On pourrait même mémoriser qui imprime quoi et quand.
Pour le tester, le plus simple est de télécharger la version monoposte, prête à l'emploi.
Sous linux, il y a un script ".sh", pour windows un exe et sous MacOS le .app qui va bien. Dans tous les cas, quelques double clic s (voir triple clics) suffiront.
Le code source arrive "bientôt", nous avons besoin d'encore un peu de temps pour factoriser des petites choses. Et comme du code sans documentation, ça ne sert a rien, on se donne quelques jours supplémentaires pour écrire de quoi bien démarrer.
Merci. 500 visites sur le site ce jour d'après google analytics, c'est encourageant.
GestionNX c'est le nom commercial de l'ancêtre de OpenConcerto. On peut voir OpenConcerto comme une synthèse des différents développements spécifiques que nous avons pu faire autours de GestionNX. L'idée est de monter en puissance niveau fonctionnalité, sous forme de modules, autours d'un noyau et réaliser les développements spécifiques en modules.
Je vois plutôt OpenConcerto comme une autre solution libre, pas vraiment un concurrent à un autre projet libre. La concurrence est à chercher du côté des éditeurs de logiciels propriétaires.
La grande différence technique est que nous avons fait le choix de ne pas baser le logiciel sur des technologies web. Pour le confort d'utilisation bien sûr, mais également pour éviter de bloquer les clients en cas de coupure internet (s'il part dans une offre hébergée).
La page support est corrigée. Merci de l'avoir signalé, il y a tellement de choses à vérifier lors d'une mise en ligne... et les yeux finissent par ne plus rien voir!
Pour la caisse, bien vu, c'est un exécutable à part que nous n'avons pas inclus pour la version 1.0. Non pas qu'elle soit non fonctionnelle, mais nécessite d'écrire une documentation. Encore un peu de patience ;)
S'interfacer aux douchettes et imprimantes tickets n'est pas forcément aisé, car ces matériels sont loin de suivre des standards. Si tu connais par coeur les modèles de matériel POS que tu veux utiliser, je me ferrais un plaisir de t'indiquer si la version actuelle est compatible.
Pas encore eu le temps d'évaluer en détail OpenBravo POS, mais je ne vois pas ce qui empêcherais de coder un import.
Pour accrocs du Java côté serveur, vous pouvez faire un tour du côté de jOpenDocument.org pour générer et manipuler des fichiers au format OpenDocument.
Très bonne remarque!
La règle la plus commune est d'arrondir chaque total afin que la somme fasse bien la somme des montants affichée (tronqués a 2 chiffres après la virgule), sinon "la" comptable va pas comprendre pourquoi 10.00 + 20.00 ca fait 30.01.
La gestion derrière, que ce soit en centimes entiers ou euros en nombres décimaux, c'est un choix. J'ai déjà vu pas pas de newbies gérer tout ca en flottant :) un vrai régal d'erreur.
8.1 stable... oui si on veut, pour avoir perdu 48h à essayer de monter un NAS ZFS+Samba avec, je ne dirais pas "boulversifiant".
Core 2 duo E7500, 8Go de mémoire, 3 DD SATA de 2To, 1 petit SSD pour le cache et c'est parti:
- samba reste bloqué à chaque connexion, sans workaround trouvé. Le problème semble assez fréquent
- pas de support du "trim" pour le SSD
- le ZFS de FreeBSD est loin d'être la dernière version, pas de déduplication et des bugfixes non inclus
Bref, sans déduplication et sans samba, reboot et install de nexenta... sans aucuns soucis. (débit 90Mo/s en lecture, et 60Mo/s en écriture avec compression gzip et déduplication)
Je me souviens d'un article sur Login expliquant que pour Intel et AMD, il est indispensable economiquement de complexifier les architectures des processeurs en augmentant le nombre de transistors.
En effet, a nombre de transistor egal, l'evolution des process de production, nous aurions dans 5 ans des Core2Duo a 12 GHz pour 10 euros!
Encore un peu de patience et le x86 sera juste un coprocesseur integre de serie a tout processeur afin de garantir la compatibilite des applications industrielles. Applications pour lesquelles un changement d'archi ne serait qu'une perte financiere sans le moindre gain de fiabilite, ou de fonctionnalite ou de performance...
Un format ne devient un standard que par son adoption massive par les utilisateurs.
OpenOffice par sa gratuité a un avantage immense pour l'utilisateur mais au niveau des développeurs, Microsoft est loin devant.
On ne compte plus le nombre d'applications qui s'interfacent à Word pour générer des documents, les afficher, ou encore les librairies .net (bien sur!) et Java pour manipuler le OOXML.
Côté OpenDocument, il reste UNO + OpenOffice, bien lourd à utiliser et peu de librairies. ( même si on si atèle activement sur http://www.jopendocument.org )
Tour de passe passe et argent ni ferront à mon avis pas grand chose au final pour Microsoft, on l'a bien vu avec Firefox.
Le tout est de tenir la barre avec un bon format et de quoi l'exploiter facilement (si possible pour pas trop cher :) ), non?
Apres une demi journee de test du 2.6 'stable' voici mes premieres impressions:
- installation : pas dur du tout a partir d'une redhat 9, redhat fournit les rpms qui vont bien
- premier boot : tout marche ou presque : le son est OK, XFree sur une GeForce4 MX aussi, pas de problemes de stabilite a l'utilisation et aussi une grande rapidite de boot et un gain de reactivite avec XFree.
L'USB a necessite quelques modifs du rc.sysinit! Un petit reboot pour voir le resultat ...
- deuxieme boot: pas de problemes avec l'USB, l'imprimante laser marche toujours... le systeme de fichier depote; le bash ne traine plus pour une grosse copie ou un "tar -zxf ". Toujours plein d'espoir, je teste Mozilla, et la grosse stupeur, Mozilla mouline pendant presque 10s a chaque fois que j'accede a une nouvelle page, pareil pour un telechargement, j'essaye la derniere version de Mozilla, idem... Opera n'a pas ce probleme, il est encore plus veloce qu'avant, c'est dire! OpenOffice, Java, tout est plus rapide, que demander de plus?
Et c'est la que ca fait mal, le graveur de CDROM LG ne lis plus les CDs, en regardant les logs, pas d'erreur, ide-scsi se lance bien... le log du kernel montre que /dev/hdc est le graveur... mais rien, mount /dev/hdc /mnt/cdrom dis que /dev/hdc n'est pas valide... :(
Et maintenant, le test ultime pour la machine: un 'sync' en tant que root, j'attend 10s et debranche la prise...
- dernier boot: le disque est vu comme not clean, recovering journal (les partitions sont en ext3) et boom la verification du filesystem annonce le verdict, il faut faire un fsck a la main, qui apres 30 mins part en vrille, reboot la machine, un demi million d'erreurs sur le disk; bye bye 2.6
Reformatage complet pour un 2.4, au moins, ca plante pas tout au premier redemarrage brutal...
Pb de securite... J'ai l'impression que pour toi, gerer la transparence dans une fenetre, c'est avoir acces aux bitmaps des fenetres en dessous pour pouvoir calculer la superposition avec les canaux alpha... effectivement ca ne serait pas 'secure'.
C'est au server a gerer la transparence, c'est a lui de faire de faire les calculs qui vont bien pour que quand une appli fait trace qq chose, le resultat a l'ecran respecte les canaux alpha.
Avec la Xlib point de canaux alpha.... avec XRender c'est possible mais ca rame enormement. ( suffit de regarder le code source des drivers pour voir qu'il n'y a pas de support de l'alpha )
Pour ceux qui y croyaient encore, je rappelle qu'en local, X utilise les sockets Unix et la SHM
Voila un autre mythe!! Il n'y a pas 5% des applis qui utilisent SHM. SHM perment de partager des bitmaps entre le client et le serveur sans le transferer par socket. MAIS il faut explicitement utiliser l'API de SHM pour ca, une appli non designe pour utiliser SHM ne le ferra pas (meme inconsciement).
Ecrire des tonnes d'extension pour XFree ne sert a rien car quel developpeur vas redesigner son applis tous les 2 ans pour rajouter partout des tests genre:
si SHM est dispo et je suis en 'local' alors je l'utilise
si XRender est dispo et est accelere en hard alors je l'utilise
etc etc....
Cote perf, meme sans utiliser autre chose que du Xlib pur, les applis pourraient etre rapides, mais ca demande enormement de temps. Sous B.E.OS (www.BlueEyedOS.com), le pari a ete pris de faire ces optimisations cote server d'application du systeme. Du coup toutes les applications utilisant l'API de B.E.OS (qui est la meme que celle de BeOS) beneficient de toutes les accelerations possible cote serveur.
# Outil de test
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Le colonel Moutarde, sur la table (de hachage), avec un livre de maths. Évalué à 1.
Au passage, un outil pour tester la faille sur son serveur perso: http://www.magic-hash.com
[^] # Re: Récurrents / abonnements
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche ERP OpenConcerto 1.1 disponible. Évalué à 3.
La gestion des affaires récurrentes est à envisager sous forme de module. Pour ce qui est des statistiques par commerciaux, on a pas encore eu le temps de l'intégrer mais on l'a sous le coude.
[^] # Re: Ensemble de questions stupides
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Lancement de la bêta d’Elveos. Évalué à 1.
Je suis preneur en MP de ce que tu lui reproches et de tes attentes.
Nous finalisons la version 1.1 et commençons la roadmap pour la 1.2, c'est donc le bon moment.
[^] # Re: Ensemble de questions stupides
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Lancement de la bêta d’Elveos. Évalué à 2.
OpenConcerto?
[^] # Re: Les développeurs Java
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 1.
Si as en tête le nom d'un profiler C/C++ qui peut rivaliser, n'hésites pas car j'ai du passé à côté. (On ne pas tout connaître et tout tester!)
J'imagine qu'il faudra tout de même recompiler l'appli... non?
[^] # Re: Les développeurs Java
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 7.
Niveau performance, sur de gros programmes, un programmeur Java avec les bons outils de profiling réussira rapidement à avoir un logiciel plus rapide que son équivalent C/C++.
Sur les micro-benchmarks, C et C++ resterons à mon avis toujours meilleurs car les performances découlent d'optimisations liées aux instructions processeurs utilisée.
En revanche, sur un logiciel de plusieurs milliers de lignes (genre au hasard OpenConcerto :) ), en quelques minutes, avec jProfiler par exemple, le coder Java voit exactement:
- où sont les hotspots à optimiser,
- quand les threads sont en attentes,
- ce qui est parallélisable
et tout cela en ayant la hiérarchie des appels, les temps moyens, les nombres d'appels et j'en passe! Beauté de la chose: cela se fait sans recompiler ou modifier quoi que soit à l'application.
Bref, l'outil étonne souvent, les pertes de performances sont rarement là où on les cherche. Ayant passé des heures à optimiser des codes assembleur, C, C++ et Java, je vois en java une excellente plateforme pour atteindre rapidement d'excellentes performance sur des logiciels de taille importante.
Pour tout ceux qui n'aurait pas encore testé un outil comme jProfiler, faites un tour sur jOpenDocument section benchmark. Après quelques heures de profiling, nous avons optimisé la génération de documents OpenDocument: 17 ms pour créer un document (dont 12ms passées dans l'accès disque) quand une autre librairie (ODFDOM) à besoin de 126ms, ça parle tout de suite!
[^] # Re: hacker
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto, la version 1.1 de l’ERP a besoin de vous !. Évalué à 1.
Pour les betas de la version 1.1, il ne faut pas être un hacker mais être assez téméraire pour configurer un serveur PostgreSQL. Le reste est une question de clics.
La betas sont disponibles depuis le forum, il reste encore un peu de travail pour fournir une version installable en 3 clics de la version 1.1 sur toutes les plateformes.
# OpenConcerto va investir 1 million d'euros dans le projet
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Partenariat FDN - No-Log - LinuxFr.org : la DLFPbox bouleverse le paysage du libre. Évalué à 1.
Fort de l'investissement de Jaïna Cpaital d'un montant de 10 millions d'euros annoncé ce jour, OpenConcerto profite de ce grand jour pour dévoiler son premier investissement: 1 million d'euros pour l'intégration de sa suite logiciel de gestion sur la DLFPBox.
Un communiqué de presse complet suivra dans quelques jours.
[^] # Re: Un ERP ?
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.0 , un nouvel ERP libre. Évalué à 2.
OpenConcerto est bel et bien un ERP. Je comprend très bien qu'on puisse facilement passer à côté vu que nous avons encore pas mal de doc à écrire :)
Pour la configuration, il ne faut pas mélanger les préférences et la configuration de l'ensemble. La gestion des droits est là et est très compléte (Menu Structure), il est possible par exemple de gérer indépendament les droits sur chaque action (tables) pour: ajout, modification, suppression et accès en lecture. Ces droits sont par utilisateur. Les menus se simplifient en fonction des droits associés. Il est possible de gérer les droits par "ensemble". Il est aussi tout à fait possible de supprimer le module de compta et de modifier les workflow.
Nous avons mis l'accent sur la possibilité de créer des modules pour ajouter des fonctionnalités, changer des comportements, faire des imports, etc... Encore un peu de patience, nous allons fournir doc et outils. Vous verrez que nous avons un système efficace d'accès aux bases de données et d'UI.
Pour les boîtes de dialogues, est ce que cela touche toutes les fenêtres du logiciel? Peut-on en savoir un peu plus sur votre distribution, version de java, etc? Le logiciel doit également mémoriser la position des fenêtres, est ce que cela fonctionne?
Que proposez vous pour remplacer le fond jaune clignotant des champs pas ou incorrectement remplis?
[^] # Re: Mocèle de développement / fi
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.0 , un nouvel ERP libre. Évalué à 2.
Nous avons déjà quelques idées pour construire un modèle économique viable (pour les utilisateurs comme pour nous).
Parmi elles:
Nous serions très contents d'avoir quelques contributions spontanées (en pub ou en code), pour cela nous préparons les documentations nécessaires.
Nous pensons aussi à mettre en place un système de mutualisation des financements de développement sur des modules. En effet, tout le monde n'a pas forcément un budget conséquent pour un logiciel de gestion.
Il n'est pas rare pour nous de voir des clients "subir" un logiciel en boîte qui ne nécessiterait pourtant que quelques modifications pour être éfficace. La politique de l'éditeur étant de faire un logiciel qui peut "convenir" à tous, ça ne risque pas d'arriver... Un bon argument pour choisir OpenConcerto.
J'imagine aussi que certains acheteurs verront en OpenConcerto une bonne base pour un système informatique performant et préféreront investir en développement une partie du budget économisé en licence.
Au risque de surprendre, même si OpenConcerto ne rapporte que quelques centimes, nous continuerons à le développer et à le faire vivre en opensource. Tout simplement car nous avons déjà des clients qui l'utilisent depuis quelques années et qui n'ont pas envie de s'en passer.
Le temps nécessaire à contribuer nos développements dans OpenConcerto est négligeable face à ce qu'un projet opensource nous apporte: visibilité et crédibilité. jOpenDocument a déjà fait beaucoup et au vu des 1400 visites enregistrées par google analytics en 2 jours pour OpenConcerto, nous sommes assez optimistes!
[^] # Re: Mocèle de développement / financement...
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.0 , un nouvel ERP libre. Évalué à 1.
Pour les screenshots, je m'y colle la semaine prochaine en oubliant pas aussi de compléter le site avec les remarques de vous tous.
[^] # Re: Wow
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.0 , un nouvel ERP libre. Évalué à 3.
Un forum, un webmail, un CMS ou un bugtracker c'est très bien dans un navigateur, mais quand il faut commencer à discuter avec une imprimante série, une douchette code à barres et un tiroir caisse... on est bien content d'avoir un peu plus que HTML/CSS/JavaScript.
[^] # Re: Application riche
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.0 , un nouvel ERP libre. Évalué à 3.
Côté "OnCloud", OpenConcerto est techniquement prêt. Base de données sur le cloud et logiciel lancé en utilisant webstart, ca fonctionne très bien sur une liaison 3G.
L'interface graphique du logiciel étant asynchrone, les problèmes liés à la latence et aux débits sont résolus. Nous avons des clients qui utilisent le logiciel à travers des liaisons VPNs en ADSL pour faire du multisite et multisociété et sont ravis de voir que les performances sont là.
Pour donner une idée des limitations que nous ne voulions pas avoir, voici un exemple concret: l'édition de facture.
Imaginons qu'un client ait dans sa "procédure qualité" la contrainte qu'une facture doit être toujours imprimée en 2 exemplaires (une pour la société, une pour le client):
- Un ERP web, proposera un bouton "imprimer" qui créera la facture (souvent en PDF) sur le serveur, l'enverra au navigateur de l'utilisateur, la visionneuse du système prendra le relais pour afficher le document, l'utilisateur cliquera "imprimer", 2 fois. Cela prend plusieurs clics et plusieurs secondes.
- Avec OpenConcerto, le bouton imprimer peut lancer directement l'impression sur l'imprimante en 2 exemplaires sans rien demander à l'utilisateur. On pourrait même mémoriser qui imprime quoi et quand.
[^] # Re: Code source et installation
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.0 , un nouvel ERP libre. Évalué à 3.
Sous linux, il y a un script ".sh", pour windows un exe et sous MacOS le .app qui va bien. Dans tous les cas, quelques double clic s (voir triple clics) suffiront.
Le code source arrive "bientôt", nous avons besoin d'encore un peu de temps pour factoriser des petites choses. Et comme du code sans documentation, ça ne sert a rien, on se donne quelques jours supplémentaires pour écrire de quoi bien démarrer.
Bons tests!
[^] # Re: Wow
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.0 , un nouvel ERP libre. Évalué à 2.
GestionNX c'est le nom commercial de l'ancêtre de OpenConcerto. On peut voir OpenConcerto comme une synthèse des différents développements spécifiques que nous avons pu faire autours de GestionNX. L'idée est de monter en puissance niveau fonctionnalité, sous forme de modules, autours d'un noyau et réaliser les développements spécifiques en modules.
Je vois plutôt OpenConcerto comme une autre solution libre, pas vraiment un concurrent à un autre projet libre. La concurrence est à chercher du côté des éditeurs de logiciels propriétaires.
La grande différence technique est que nous avons fait le choix de ne pas baser le logiciel sur des technologies web. Pour le confort d'utilisation bien sûr, mais également pour éviter de bloquer les clients en cas de coupure internet (s'il part dans une offre hébergée).
[^] # Re: Ou es le module de caisse ?
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.0 , un nouvel ERP libre. Évalué à 3.
Pour la caisse, bien vu, c'est un exécutable à part que nous n'avons pas inclus pour la version 1.0. Non pas qu'elle soit non fonctionnelle, mais nécessite d'écrire une documentation. Encore un peu de patience ;)
S'interfacer aux douchettes et imprimantes tickets n'est pas forcément aisé, car ces matériels sont loin de suivre des standards. Si tu connais par coeur les modèles de matériel POS que tu veux utiliser, je me ferrais un plaisir de t'indiquer si la version actuelle est compatible.
Pas encore eu le temps d'évaluer en détail OpenBravo POS, mais je ne vois pas ce qui empêcherais de coder un import.
# Pour le site web Java
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Un point sur l'export ODT pour les applications web. Évalué à 2.
Les performances sont au rendez-vous.
[^] # Re: Il faut saluer les développeurs
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche PhpCompta sortie de la version 5.2. Évalué à 3.
La règle la plus commune est d'arrondir chaque total afin que la somme fasse bien la somme des montants affichée (tronqués a 2 chiffres après la virgule), sinon "la" comptable va pas comprendre pourquoi 10.00 + 20.00 ca fait 30.01.
La gestion derrière, que ce soit en centimes entiers ou euros en nombres décimaux, c'est un choix. J'ai déjà vu pas pas de newbies gérer tout ca en flottant :) un vrai régal d'erreur.
[^] # Re: Stable...
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Sortie de FreeBSD 8.1-RELEASE. Évalué à 2.
# Stable...
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Sortie de FreeBSD 8.1-RELEASE. Évalué à 3.
Core 2 duo E7500, 8Go de mémoire, 3 DD SATA de 2To, 1 petit SSD pour le cache et c'est parti:
- samba reste bloqué à chaque connexion, sans workaround trouvé. Le problème semble assez fréquent
- pas de support du "trim" pour le SSD
- le ZFS de FreeBSD est loin d'être la dernière version, pas de déduplication et des bugfixes non inclus
Bref, sans déduplication et sans samba, reboot et install de nexenta... sans aucuns soucis. (débit 90Mo/s en lecture, et 60Mo/s en écriture avec compression gzip et déduplication)
Guillaume
[^] # Re: Je suis pas fashion, je sais...
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche La virtualisation et le libre : où en est-on ?. Évalué à 2.
En effet, a nombre de transistor egal, l'evolution des process de production, nous aurions dans 5 ans des Core2Duo a 12 GHz pour 10 euros!
Encore un peu de patience et le x86 sera juste un coprocesseur integre de serie a tout processeur afin de garantir la compatibilite des applications industrielles. Applications pour lesquelles un changement d'archi ne serait qu'une perte financiere sans le moindre gain de fiabilite, ou de fonctionnalite ou de performance...
Je dois etre demode aussi ! ;)
# Verroux
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche La normalisation de OOXML relance le RGI.. Évalué à 1.
Un format ne devient un standard que par son adoption massive par les utilisateurs.
OpenOffice par sa gratuité a un avantage immense pour l'utilisateur mais au niveau des développeurs, Microsoft est loin devant.
On ne compte plus le nombre d'applications qui s'interfacent à Word pour générer des documents, les afficher, ou encore les librairies .net (bien sur!) et Java pour manipuler le OOXML.
Côté OpenDocument, il reste UNO + OpenOffice, bien lourd à utiliser et peu de librairies. ( même si on si atèle activement sur http://www.jopendocument.org )
Tour de passe passe et argent ni ferront à mon avis pas grand chose au final pour Microsoft, on l'a bien vu avec Firefox.
Le tout est de tenir la barre avec un bon format et de quoi l'exploiter facilement (si possible pour pas trop cher :) ), non?
# Pas encore pour moi
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Le noyau Linux 2.6.0 annoncé stable. Évalué à 1.
- installation : pas dur du tout a partir d'une redhat 9, redhat fournit les rpms qui vont bien
- premier boot : tout marche ou presque : le son est OK, XFree sur une GeForce4 MX aussi, pas de problemes de stabilite a l'utilisation et aussi une grande rapidite de boot et un gain de reactivite avec XFree.
L'USB a necessite quelques modifs du rc.sysinit! Un petit reboot pour voir le resultat ...
- deuxieme boot: pas de problemes avec l'USB, l'imprimante laser marche toujours... le systeme de fichier depote; le bash ne traine plus pour une grosse copie ou un "tar -zxf ". Toujours plein d'espoir, je teste Mozilla, et la grosse stupeur, Mozilla mouline pendant presque 10s a chaque fois que j'accede a une nouvelle page, pareil pour un telechargement, j'essaye la derniere version de Mozilla, idem... Opera n'a pas ce probleme, il est encore plus veloce qu'avant, c'est dire! OpenOffice, Java, tout est plus rapide, que demander de plus?
Et c'est la que ca fait mal, le graveur de CDROM LG ne lis plus les CDs, en regardant les logs, pas d'erreur, ide-scsi se lance bien... le log du kernel montre que /dev/hdc est le graveur... mais rien, mount /dev/hdc /mnt/cdrom dis que /dev/hdc n'est pas valide... :(
Et maintenant, le test ultime pour la machine: un 'sync' en tant que root, j'attend 10s et debranche la prise...
- dernier boot: le disque est vu comme not clean, recovering journal (les partitions sont en ext3) et boom la verification du filesystem annonce le verdict, il faut faire un fsck a la main, qui apres 30 mins part en vrille, reboot la machine, un demi million d'erreurs sur le disk; bye bye 2.6
Reformatage complet pour un 2.4, au moins, ca plante pas tout au premier redemarrage brutal...
Guillaume
[^] # Re: Après X, voici Y...
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Après X, voici Y.... Évalué à 1.
Pb de securite... J'ai l'impression que pour toi, gerer la transparence dans une fenetre, c'est avoir acces aux bitmaps des fenetres en dessous pour pouvoir calculer la superposition avec les canaux alpha... effectivement ca ne serait pas 'secure'.
C'est au server a gerer la transparence, c'est a lui de faire de faire les calculs qui vont bien pour que quand une appli fait trace qq chose, le resultat a l'ecran respecte les canaux alpha.
Avec la Xlib point de canaux alpha.... avec XRender c'est possible mais ca rame enormement. ( suffit de regarder le code source des drivers pour voir qu'il n'y a pas de support de l'alpha )
[^] # Re: Après X, voici Y...
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Après X, voici Y.... Évalué à 1.
Voila un autre mythe!! Il n'y a pas 5% des applis qui utilisent SHM. SHM perment de partager des bitmaps entre le client et le serveur sans le transferer par socket. MAIS il faut explicitement utiliser l'API de SHM pour ca, une appli non designe pour utiliser SHM ne le ferra pas (meme inconsciement).
Ecrire des tonnes d'extension pour XFree ne sert a rien car quel developpeur vas redesigner son applis tous les 2 ans pour rajouter partout des tests genre:
si SHM est dispo et je suis en 'local' alors je l'utilise
si XRender est dispo et est accelere en hard alors je l'utilise
etc etc....
Les problemes de X sont exposes ici:
http://www.osnews.com/story.php?news_id=1905(...)
Cote perf, meme sans utiliser autre chose que du Xlib pur, les applis pourraient etre rapides, mais ca demande enormement de temps. Sous B.E.OS (www.BlueEyedOS.com), le pari a ete pris de faire ces optimisations cote server d'application du systeme. Du coup toutes les applications utilisant l'API de B.E.OS (qui est la meme que celle de BeOS) beneficient de toutes les accelerations possible cote serveur.