Les deux versions vont partager plus de 90% de leur code, donc à part si plus aucun de nos clients ne veulent utiliser la version desktop, nous continuerons à faire évoluer les deux.
Par contre, vu que l'on sortira une version desktop "client léger", elle risque de prendre le pas sur la version classique dans le coeur des utilisateurs.
Ensuite ce bouton fait appel a du code coté backend
C'est justement le point bloquant. Difficile pour le backend de discuter avec un port USB ou série branché sur le poste local, idem pour les lecteurs RFID, les scanners, et les services du système d'exploitation en général.
Odoo a tendance a contourner avec une approche 100% réseau, quitte à utiliser un Raspberry comme passerelle. Cette approche n'est pas forcement simple ou possible à mettre en œuvre, surtout quand le serveur est sur le cloud.
Le xpath est compilé à la volée lors de la mise à jour du module du coups les erreurs sont détectées immédiatement
Je ne pensais pas forcément à des erreurs syntaxiques. De mon point de vue, une API permet des interactions et des vérifications bien plus poussées qu'un simple fichier de description.
Dans le cas d'Odoo, en plus du xml il faut ajouter un peu de Python pour sortir du cas simple. N'ayant pas vraiment d'expérience dans ce domaine, je ne saurais dire si c'est gênant ou pas.
La version web a été présentée dans la vidéo du live. Cette version sortira cette année, difficile de dire quand, la crise sanitaire et divers gros projets ont "un peu" chahuté nos plannings.
Pour Dolibarr, on ne le voit que par le prisme des clients qui souhaitent migrer vers OpenConcerto, de ce qu'il en ressort c'est effectivement une certaine latence pour la résolution de bugs (un peu plus de 800 bugs non corrigé à ce jour…) et pour les évolutions réglementaires.
Pour les micros budgets, Dolibarr c'est très bien. J'ai vu passé des hébergement "illimité" à 5€ par mois.
Le "framework" d'OpenConcerto dédié aux accès base de données supporte MySQL, PostgreSQL, SQLServer et H2, il a donc fallu trouver des dénominateurs communs fiables.
Parmi eux: imposer ces "fameux" guillemets sur les noms et les 'quotes' sur les valeurs, car leurs interprétations dépendent de le base de données ET de leurs réglages par défaut.
En conséquence, mettre les tables en majuscule a été le moyen le plus simple pour décourager fortement l'écritures de SQL à la main, le framework s'occupant de la syntaxe et des bizarreries des différents systèmes.
Je ne dénigre pas Node.js ou la tendance NoSQL. Techniquement je vois juste mal comment garantir une comptabilité correcte sans contraintes fortes, ni comment maintenir le demi million de lignes de code Javascript nécessaire à un logiciel qui doit s'occuper de comptabilité, gestion commerciale, paye, etc…
Dolibarr n'est pas un mauvais choix, peut-être que la version web d'OpenConcerto placera ce dernier comme une alternative pour ceux qui ne jurent que par le "zéro install" des applications web. Wait&See.
Effectivement, l'IHM c'est avant tout une histoire d'efficacité et de lisibilité.
On travaille sur l'interface web d'OpenConcerto, en complément de l'interface native.
Je doute que l'on puisse rivaliser avec ce que l'on peut faire sur desktop en standard (multifenêtre, drag&drop, contrôle totale de l'UI, etc…) sans compter les interactions avec l'OS et le matériel (bon courage pour imprimer sur une imprimante d'étiquette industrielle type Zebra depuis le web).
J'ai l'impression qu'il y a une certaine confusion chez les utilisateurs entre "moderne" et "web". Faute surement aux aficionados du html et du javascript, ou de commerciaux pas forcement très calés en IHM.
Au passage, je trouve la situation des développements sur tablettes et téléphones assez ironique, tout le monde plébiscite les applications mobiles natives.
Niveau "extensibilité", cad le point important pour un ERP, de ce que je connais d'Odoo, il s'en sort très bien.
Je ne vois pas spécialement de limite à l'extensibilité d'OpenConcerto, nous avons un système de modules, d'interfaces graphiques dynamiques, etc… dans l'implémentation, l'approche est bien différente, le typage "fort" de Java permet certaines vérifications à la compilation. De plus, nous évitons les fichiers de description (xml, json,…) au maximum pour s'affranchir des erreurs de frappes que l'on ne découvre qu'à l'exécution (de mémoire les interfaces d'Odoo sont décrites en xml (+xpath)).
Vous êtes de mauvais poil aujourd'hui vous deux ou est-ce un nouveau sport de balancer des trucs négatifs en mode maxi-flou, le tout de l'ordre d'un ressenti ineffable?
Bref, c'est quoi un look 1990/2000 ? C'est quoi un code 1990/2000 ?
Vous connaissez un peu les logiciels majeurs du marché pour comparer?
Si vous voulez un machin en Node.js et NoSQL, des polices en tailles 32 en mode arc en ciel, vous allez en effet être déçu.
Est ce que l'on propose des sessions de formation dans des cadres paradisiaque?
Non. Mais on garde l'idée pour les clients ayant envie de financer ce genre de chose ;)
Plus sérieusement, pour ce qui est d'une base de données exemple, OpenConcerto est livré de base avec une base contenant quelques clients, fournisseurs, devis, factures, etc… et rien n'empêche de vous en faire une.
Oulala, les gris de l'interface ne sont plus vraiment gris et vont fausser l'affinage colorimétrique des millions d'images :)
Je plaisante bien sur! (faut avoir suivi les autres dépêches pour comprendre…)
Le passage à GTK3 est une belle avancée et le changelog bien costaud.
N'étant pourtant pas le dernier à soutenir (et aussi créer) des logiciels libres, je trouve tout cela bien approximatif.
Les logiciels Autodesk et Adobe n'ont pas à ce jour d'équivalent libre, je côtoie assez d'utilisateurs professionnels pour en être absolument convaincu (non pas par de la rhétorique mais par les faits).
Les logiciels libres sont souvent limités par le budget, ce qui se traduit par : petite équipe, documentation mince, suite de tests rares, suivi de version aléatoire, support professionnel inexistant ou lacunaire.
Combien de développeurs à temps complet rémunérés pour GIMP vs Photoshop, LibreOffice vs MS Office?
Le ratio est tellement important que le talent des uns ne peut pas rivaliser avec les moyens des autres.
Et encore… avez vous goûté au publipostage sur LibreOffice?
Imaginons que demain une vraie alternative libre, à par exemple InDesign, soit proposée par un éditeur, qui sera prêt à payer autant (voir plus) que ce que facture Adobe?
(afin que le logiciel puisse fournir le même niveau de stabilité, documentation et support)
Personne.
(à charge: ces 20 dernières années)
Les seuls logiciels libres qui s'en sortent aussi bien que les logiciels propriétaires sont ceux financés par de gros acteurs pour leurs besoins.
J'aimerais vraiment bien qu'un jour, on ait un vrai financement qui permette d'avoir un salaire décent pour le projet, et même d'engager d'autres gens! (petit rêve d'un studio d'animation qui fait des films libres avec plein d'artistes et plein de développeurs qui améliorent les logiciels libres! Mais bon pour l'instant, on n'arrive même pas à avoir de quoi payer un seul temps plein au SMIC, alors notre rêve… on en est loin)
Peut être qu'il est temps de mettre côté les corrections et développements de nouvelles fonctionnalités, pour s'occuper de ce point, que me semble être d'une priorité quasi absolue, car conditionne le reste.
Nul besoin de m'incendier avec des "oui bien sur, yaka" ou "plus facile à dire qu'à faire".
Il est beaucoup plus facile de s'occuper du "commercial" que de coder.
Une partie des utilisateurs est surement prête à acheter quelques choses, ça peut être un manuel, l'accès à des versions "bleeding edge", etc…
Bref, pas envie de m’étendre la dessus, car beaucoup d’énergie va être déployer pour m'expliquer qu'il ne faut pas faire ci ou ça…
Dans le "monde" des ERPs, la montée en version est payante dans la majorité des cas.
Pire encore, elle est parfois impossible.
Avec OpenConcerto, nous récupérons des clients Sage (principalement, mais pas seulement) qui n'ont pas mis à jour leur logiciels pendant plus de 5 ans. Devant se mettre à la page, ils décident "d'acheter" la nouvelle version à prix d'or, car trop leur version est trop ancienne pour juste "acheter" une mise à jour. Petit hic, l'éditeur ne sait pas (ou "plus") migrer les données de son propre logiciel.
Sur le papier, proposer des mises à jour de base de données c'est assez simple.
Dès que l'on manipule des centaines de tables, soit des milliers et des milliers de champs, ça devient compliqué car chaque module (même non customisé) peut monter en version indépendamment des autres et utiliser des champs "communs".
Au final, on se retrouve a garantir que chaque module peut monter en version individuellement, mais l'ensemble des modules, pris à des versions différentes, l'opération est plus coton. Les changements de structure de base nécessitent des petits programmes ("moulinettes") qui vont "redispatcher" les données, programmes qui doivent être assez clairvoyantes pour anticiper les changements apportées aux données par d'autres modules.
C'est d'ailleurs pourquoi dans le cas d'OpenConcerto, pour passer de la version 1.3.2 à la version 1.6.3, il faut passer par la version 1.4, 1.5, 1.6 puis 1.6.3.
Dans le cas d'Odoo, la mise au point de l'upgrade doit être titanesque, pas étonnant donc qu'elle soit payante vu la complexité et le risque de problèmes.
(ici on parle de données critiques pour l'entreprise, pas de place pour la bidouille).
Développer ce genre de solution soi même ne coûte en effet presque rien en matériel, mais que dire du temps passé ?
Je serais assez curieux de savoir combien tu facturerais un tel développement si quelqu'un te demandait de le faire (en partant de rien comme tu l'as fait).
il est plus simple de falsifier une compta informatique que papier (d'où la fameuse loi de finance visant à rendre plus facilement auditable les logiciels de caisse, suite à de nombreuses fraudes permises volontairement par certains éditeurs). Une ligne barrée, modifiée, une page manquante, ça se voit facilement sur un libre de vente.
arrondir est commun et est parfaitement légal si favorable au client. Cela permet de se simplifier la vie dans la gestion de caisse.
concernant les banques, les encaissements de toute nature (pas que les CBs) sont "taxés", en moyenne à 0.5%, ce qui est loin d'être négligeable.
Les commerçants gérant seuls leur magasin ne sont pas la cible d'OpenConcerto.
OpenConcerto s'adresse plutôt à des sociétés qui ont besoin d'un ERP pour structurer leur activité, à la différences du "petit commercant" qui ne perçoit le logiciel que comme une "obligation" qui coûte cher (donc séduit par l'opensource uniquement pour des raisons financières).
C'est effectivement très valable comme approche pour un informaticien qui ne compte pas son temps.
J'ai préparé tranquillement cet hiver, et j'ai bloqué une semaine de boulot pendant l'été pour la migration proprement dite, les tests et le déploiement.
Breaking news : j'ai retenté de récupérer le domaine. Avec bien du mal et quelques euros, il a retrouvé le chemin vers son propriétaire. Ca sera l'occasion d'enterrer le projet proprement.
C'est vraiment se casser la tête pour pas grand chose.
Que reste t'il dans la bibliothèque de logiciels de BeOS qui vaille encore le coût de maintenir une compatibilité binaire ? (oui, je sais, j'ai déjà posé la question en 2003 ;) )
Une deuxième façon de faire est de versionner les binaires (pas les libs ni le système) et de les patcher au 1er lancement si besoin.
Pour BlueEyedOS, il n'y a jamais eu de sources publiées, ça n'a pas du aider le projet à rester vivant non plus.
En 2000, nous n'avions pas les moyens (financiers) de fournir facilement un "repository" public.
Après avoir été viré de OpenBeOS (ancien nom de Haiku), je me suis tout de même arrangé pour que le code de BlueEyedOS qui pouvait être utile à Haiku arrive à destination…
Ce que je retiens de cette période c'est que le projet qui faisait le plus rêver a le plus plu,
c'est pourquoi Haiku a survécu.
Les benchmarks ont tous démontré que sur une même machine (mon biprocesseur Pentium 3), Linux était 10 à 100 plus rapide que BeOS (BeOS 5), notamment sur les IPCs, qui sont centraux dans fonctionnement de BeOS.
Je ne sais pas où en est Haiku aujourd'hui, mais vu différence de taille entre l'équipe de dev des noyau linux et Haiku, la voie choisit par BlueEyedOS me semble toujours pertinente (techniquement).
Personnellement, tout ce que je retiens de tout cela est que tout est prêt à quitter Windows ou MacOS, mais personne n'est présent pour contribuer ou financer pour une alternative pour le "desktop" (à part Mark Shuttleworth ;) ).
Ici même, j'avais parié ici à l'époque que dans 10 ans, rien n'aurait bougé.
20 ans après c'est l'occasion de renouvelé ce triste pari.
La dessus, je peux vous répondre :)
OVH, du temps où c'était encore une petite boite avait un backoffice buggé à souhait, je n'ai pas pu renouveler le nom de domaine de ce fait, le "support client" n'a pas traité le problème, un cybersquatteur est passé par là.
Il paye d'ailleurs toujours l'hébergement, car il a inséré tout un tas de lien vers de la pub ou je ne sais quoi pour profiter du bon référencement du site.
Cette perte a achevé l'équipe, à cette date déjà plus très grande.
Dommage on avait un LiveCD avec une UI fonctionnelle (mais pas de desktop ou autre encore).
[^] # Re: Des précisions
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.7. Évalué à 7.
Les deux versions vont partager plus de 90% de leur code, donc à part si plus aucun de nos clients ne veulent utiliser la version desktop, nous continuerons à faire évoluer les deux.
Par contre, vu que l'on sortira une version desktop "client léger", elle risque de prendre le pas sur la version classique dans le coeur des utilisateurs.
[^] # Re: Trés intéressant, développez la partie migration
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.7. Évalué à 4.
C'est justement le point bloquant. Difficile pour le backend de discuter avec un port USB ou série branché sur le poste local, idem pour les lecteurs RFID, les scanners, et les services du système d'exploitation en général.
Odoo a tendance a contourner avec une approche 100% réseau, quitte à utiliser un Raspberry comme passerelle. Cette approche n'est pas forcement simple ou possible à mettre en œuvre, surtout quand le serveur est sur le cloud.
Je ne pensais pas forcément à des erreurs syntaxiques. De mon point de vue, une API permet des interactions et des vérifications bien plus poussées qu'un simple fichier de description.
Dans le cas d'Odoo, en plus du xml il faut ajouter un peu de Python pour sortir du cas simple. N'ayant pas vraiment d'expérience dans ce domaine, je ne saurais dire si c'est gênant ou pas.
[^] # Re: ERP intéressant
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.7. Évalué à 7.
La version web a été présentée dans la vidéo du live. Cette version sortira cette année, difficile de dire quand, la crise sanitaire et divers gros projets ont "un peu" chahuté nos plannings.
Pour Dolibarr, on ne le voit que par le prisme des clients qui souhaitent migrer vers OpenConcerto, de ce qu'il en ressort c'est effectivement une certaine latence pour la résolution de bugs (un peu plus de 800 bugs non corrigé à ce jour…) et pour les évolutions réglementaires.
Pour les micros budgets, Dolibarr c'est très bien. J'ai vu passé des hébergement "illimité" à 5€ par mois.
[^] # Re: ERP intéressant
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.7. Évalué à 10.
La réponse va vous surprendre :)
Le "framework" d'OpenConcerto dédié aux accès base de données supporte MySQL, PostgreSQL, SQLServer et H2, il a donc fallu trouver des dénominateurs communs fiables.
Parmi eux: imposer ces "fameux" guillemets sur les noms et les 'quotes' sur les valeurs, car leurs interprétations dépendent de le base de données ET de leurs réglages par défaut.
En conséquence, mettre les tables en majuscule a été le moyen le plus simple pour décourager fortement l'écritures de SQL à la main, le framework s'occupant de la syntaxe et des bizarreries des différents systèmes.
[^] # Re: ERP intéressant
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.7. Évalué à 5.
Merci.
Je ne dénigre pas Node.js ou la tendance NoSQL. Techniquement je vois juste mal comment garantir une comptabilité correcte sans contraintes fortes, ni comment maintenir le demi million de lignes de code Javascript nécessaire à un logiciel qui doit s'occuper de comptabilité, gestion commerciale, paye, etc…
Dolibarr n'est pas un mauvais choix, peut-être que la version web d'OpenConcerto placera ce dernier comme une alternative pour ceux qui ne jurent que par le "zéro install" des applications web. Wait&See.
[^] # Re: Trés intéressant, développez la partie migration
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.7. Évalué à 6.
Effectivement, l'IHM c'est avant tout une histoire d'efficacité et de lisibilité.
On travaille sur l'interface web d'OpenConcerto, en complément de l'interface native.
Je doute que l'on puisse rivaliser avec ce que l'on peut faire sur desktop en standard (multifenêtre, drag&drop, contrôle totale de l'UI, etc…) sans compter les interactions avec l'OS et le matériel (bon courage pour imprimer sur une imprimante d'étiquette industrielle type Zebra depuis le web).
J'ai l'impression qu'il y a une certaine confusion chez les utilisateurs entre "moderne" et "web". Faute surement aux aficionados du html et du javascript, ou de commerciaux pas forcement très calés en IHM.
Au passage, je trouve la situation des développements sur tablettes et téléphones assez ironique, tout le monde plébiscite les applications mobiles natives.
Niveau "extensibilité", cad le point important pour un ERP, de ce que je connais d'Odoo, il s'en sort très bien.
Je ne vois pas spécialement de limite à l'extensibilité d'OpenConcerto, nous avons un système de modules, d'interfaces graphiques dynamiques, etc… dans l'implémentation, l'approche est bien différente, le typage "fort" de Java permet certaines vérifications à la compilation. De plus, nous évitons les fichiers de description (xml, json,…) au maximum pour s'affranchir des erreurs de frappes que l'on ne découvre qu'à l'exécution (de mémoire les interfaces d'Odoo sont décrites en xml (+xpath)).
[^] # Re: OpenOffice -> LibreOffice ?
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.7. Évalué à 9.
Bonjour,
Bien vu, généralement nous mentionnons les deux!
La page sur la gestion commerciale est actualisée.
Merci.
[^] # Re: Des précisions
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.7. Évalué à 8.
Quelques compléments :
Les OpenJDK 8 à 14 sont supportés.
Pour ce qui est du logiciel à installer sur les postes, la prochaine version (2.0) aura également une version Web.
[^] # Re: ERP intéressant
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.7. Évalué à 10.
Vous êtes de mauvais poil aujourd'hui vous deux ou est-ce un nouveau sport de balancer des trucs négatifs en mode maxi-flou, le tout de l'ordre d'un ressenti ineffable?
Bref, c'est quoi un look 1990/2000 ? C'est quoi un code 1990/2000 ?
Vous connaissez un peu les logiciels majeurs du marché pour comparer?
Si vous voulez un machin en Node.js et NoSQL, des polices en tailles 32 en mode arc en ciel, vous allez en effet être déçu.
[^] # Re: Des base exemple ?
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche OpenConcerto 1.7. Évalué à 5.
Bonjour,
Non. Mais on garde l'idée pour les clients ayant envie de financer ce genre de chose ;)
Plus sérieusement, pour ce qui est d'une base de données exemple, OpenConcerto est livré de base avec une base contenant quelques clients, fournisseurs, devis, factures, etc… et rien n'empêche de vous en faire une.
[^] # Re: Nausée
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Sortie de Cassandre 4.0.0, un cadriciel pour développer votre propre « trading bot ». Évalué à 3.
Avant de répondre "N'importe quoi.", merci de balancer quelques chiffres sourcés.
Ca sera beaucoup plus crédible et intéressant.
# Gris
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche 25 ans de GIMP et version de développement 2.99.2 : premiers pas vers GIMP 3 !. Évalué à 4.
Oulala, les gris de l'interface ne sont plus vraiment gris et vont fausser l'affinage colorimétrique des millions d'images :)
Je plaisante bien sur! (faut avoir suivi les autres dépêches pour comprendre…)
Le passage à GTK3 est une belle avancée et le changelog bien costaud.
[^] # Re: Faut être un peu lucide aussi ... sinon c'est contre productif !
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Solidatech : un programme qui entrave le développement du Libre en milieu associatif. Évalué à 1.
N'étant pourtant pas le dernier à soutenir (et aussi créer) des logiciels libres, je trouve tout cela bien approximatif.
Les logiciels Autodesk et Adobe n'ont pas à ce jour d'équivalent libre, je côtoie assez d'utilisateurs professionnels pour en être absolument convaincu (non pas par de la rhétorique mais par les faits).
Les logiciels libres sont souvent limités par le budget, ce qui se traduit par : petite équipe, documentation mince, suite de tests rares, suivi de version aléatoire, support professionnel inexistant ou lacunaire.
Combien de développeurs à temps complet rémunérés pour GIMP vs Photoshop, LibreOffice vs MS Office?
Le ratio est tellement important que le talent des uns ne peut pas rivaliser avec les moyens des autres.
Et encore… avez vous goûté au publipostage sur LibreOffice?
Imaginons que demain une vraie alternative libre, à par exemple InDesign, soit proposée par un éditeur, qui sera prêt à payer autant (voir plus) que ce que facture Adobe?
(afin que le logiciel puisse fournir le même niveau de stabilité, documentation et support)
Personne.
(à charge: ces 20 dernières années)
Les seuls logiciels libres qui s'en sortent aussi bien que les logiciels propriétaires sont ceux financés par de gros acteurs pour leurs besoins.
[^] # Re: L'animation dans GIMP ?
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche GIMP 2.10.22 : consolidation des formats. Évalué à -1.
Peut être qu'il est temps de mettre côté les corrections et développements de nouvelles fonctionnalités, pour s'occuper de ce point, que me semble être d'une priorité quasi absolue, car conditionne le reste.
Nul besoin de m'incendier avec des "oui bien sur, yaka" ou "plus facile à dire qu'à faire".
Il est beaucoup plus facile de s'occuper du "commercial" que de coder.
Une partie des utilisateurs est surement prête à acheter quelques choses, ça peut être un manuel, l'accès à des versions "bleeding edge", etc…
Bref, pas envie de m’étendre la dessus, car beaucoup d’énergie va être déployer pour m'expliquer qu'il ne faut pas faire ci ou ça…
[^] # Re: procédure de mise à jour
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Sortie d’Odoo 14. Évalué à 8. Dernière modification le 06 octobre 2020 à 12:18.
Dans le "monde" des ERPs, la montée en version est payante dans la majorité des cas.
Pire encore, elle est parfois impossible.
Avec OpenConcerto, nous récupérons des clients Sage (principalement, mais pas seulement) qui n'ont pas mis à jour leur logiciels pendant plus de 5 ans. Devant se mettre à la page, ils décident "d'acheter" la nouvelle version à prix d'or, car trop leur version est trop ancienne pour juste "acheter" une mise à jour. Petit hic, l'éditeur ne sait pas (ou "plus") migrer les données de son propre logiciel.
Sur le papier, proposer des mises à jour de base de données c'est assez simple.
Dès que l'on manipule des centaines de tables, soit des milliers et des milliers de champs, ça devient compliqué car chaque module (même non customisé) peut monter en version indépendamment des autres et utiliser des champs "communs".
Au final, on se retrouve a garantir que chaque module peut monter en version individuellement, mais l'ensemble des modules, pris à des versions différentes, l'opération est plus coton. Les changements de structure de base nécessitent des petits programmes ("moulinettes") qui vont "redispatcher" les données, programmes qui doivent être assez clairvoyantes pour anticiper les changements apportées aux données par d'autres modules.
C'est d'ailleurs pourquoi dans le cas d'OpenConcerto, pour passer de la version 1.3.2 à la version 1.6.3, il faut passer par la version 1.4, 1.5, 1.6 puis 1.6.3.
Dans le cas d'Odoo, la mise au point de l'upgrade doit être titanesque, pas étonnant donc qu'elle soit payante vu la complexité et le risque de problèmes.
(ici on parle de données critiques pour l'entreprise, pas de place pour la bidouille).
[^] # Re: effectivement
Posté par Guillaume Maillard (site web personnel) . En réponse au journal ovh.fr , exemple de ce qu'il ne faut pas faire avec un certificat. Évalué à 4.
J'aime beaucoup le "c'est pour ça".
Donc, si la durée de validité est 4 fois plus courte, il n'y aura pas 4 fois plus de loupés?
Par quelle magie?
[^] # Re: s'il le veut, il peut
Posté par Guillaume Maillard (site web personnel) . En réponse au journal Comment quitter Odoo Enterprise ?. Évalué à 5.
Merci pour ces précisions. Super boulot.
[^] # Re: s'il le veut, il peut
Posté par Guillaume Maillard (site web personnel) . En réponse au journal Comment quitter Odoo Enterprise ?. Évalué à 5.
Développer ce genre de solution soi même ne coûte en effet presque rien en matériel, mais que dire du temps passé ?
Je serais assez curieux de savoir combien tu facturerais un tel développement si quelqu'un te demandait de le faire (en partant de rien comme tu l'as fait).
[^] # Re: À l'ancienne
Posté par Guillaume Maillard (site web personnel) . En réponse au journal Comment quitter Odoo Enterprise ?. Évalué à 9.
Permets moi d'ajouter quelques remarques :
[^] # Re: OpenConcerto
Posté par Guillaume Maillard (site web personnel) . En réponse au journal Comment quitter Odoo Enterprise ?. Évalué à 4.
Les commerçants gérant seuls leur magasin ne sont pas la cible d'OpenConcerto.
OpenConcerto s'adresse plutôt à des sociétés qui ont besoin d'un ERP pour structurer leur activité, à la différences du "petit commercant" qui ne perçoit le logiciel que comme une "obligation" qui coûte cher (donc séduit par l'opensource uniquement pour des raisons financières).
[^] # Re: Community c'est très bien
Posté par Guillaume Maillard (site web personnel) . En réponse au journal Comment quitter Odoo Enterprise ?. Évalué à 5.
C'est effectivement très valable comme approche pour un informaticien qui ne compte pas son temps.
Prestation qui se facturerait combien?
[^] # Re: Amusant que Haiku soit le seul survivant
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 4.
Breaking news : j'ai retenté de récupérer le domaine. Avec bien du mal et quelques euros, il a retrouvé le chemin vers son propriétaire. Ca sera l'occasion d'enterrer le projet proprement.
[^] # Re: mode 'brut'
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 3.
C'est vraiment se casser la tête pour pas grand chose.
Que reste t'il dans la bibliothèque de logiciels de BeOS qui vaille encore le coût de maintenir une compatibilité binaire ? (oui, je sais, j'ai déjà posé la question en 2003 ;) )
Une deuxième façon de faire est de versionner les binaires (pas les libs ni le système) et de les patcher au 1er lancement si besoin.
[^] # Re: Amusant que Haiku soit le seul survivant
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 7.
En 2000, nous n'avions pas les moyens (financiers) de fournir facilement un "repository" public.
Après avoir été viré de OpenBeOS (ancien nom de Haiku), je me suis tout de même arrangé pour que le code de BlueEyedOS qui pouvait être utile à Haiku arrive à destination…
Ce que je retiens de cette période c'est que le projet qui faisait le plus rêver a le plus plu,
c'est pourquoi Haiku a survécu.
Les benchmarks ont tous démontré que sur une même machine (mon biprocesseur Pentium 3), Linux était 10 à 100 plus rapide que BeOS (BeOS 5), notamment sur les IPCs, qui sont centraux dans fonctionnement de BeOS.
Je ne sais pas où en est Haiku aujourd'hui, mais vu différence de taille entre l'équipe de dev des noyau linux et Haiku, la voie choisit par BlueEyedOS me semble toujours pertinente (techniquement).
Personnellement, tout ce que je retiens de tout cela est que tout est prêt à quitter Windows ou MacOS, mais personne n'est présent pour contribuer ou financer pour une alternative pour le "desktop" (à part Mark Shuttleworth ;) ).
Ici même, j'avais parié ici à l'époque que dans 10 ans, rien n'aurait bougé.
20 ans après c'est l'occasion de renouvelé ce triste pari.
[^] # Re: Amusant que Haiku soit le seul survivant
Posté par Guillaume Maillard (site web personnel) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 8.
La dessus, je peux vous répondre :)
OVH, du temps où c'était encore une petite boite avait un backoffice buggé à souhait, je n'ai pas pu renouveler le nom de domaine de ce fait, le "support client" n'a pas traité le problème, un cybersquatteur est passé par là.
Il paye d'ailleurs toujours l'hébergement, car il a inséré tout un tas de lien vers de la pub ou je ne sais quoi pour profiter du bon référencement du site.
Cette perte a achevé l'équipe, à cette date déjà plus très grande.
Dommage on avait un LiveCD avec une UI fonctionnelle (mais pas de desktop ou autre encore).