Coren a écrit 30 commentaires

Voici quelques photos :

En fait, ça a été déclaré à Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900036

En mai. Le paquet en sid va finir par arriver en buster et backports, sans doute.

Je confirme.

Il faut ajouter manuellement la clé publique de l'AC dans son navigateur si on souhaite faire ce genre d'usage.

Pour chiffrer les communications entre logiciels serveurs, là par contre, ça marche et ça évite la possibilité d'attaque par l'homme (de la terre) du milieu.

La conf mdadm était bien présente et fonctionnelle. Le raid était déjà là, présent et fonctionnel en kernel 2.6.32.

J'ai cherché pendant très longtemps un problème vis à vis de mdadm, alors qu'il était beaucoup plus basiquement dans initramfs directement.

Oui, c'est un workaround.

Le bug est connu:
http://www.mail-archive.com/debian-bugs-rc@lists.debian.org/msg153699.html

Et n'est visiblement pas vraiment résolu…

Le produit est rapide et intuitif, comme annoncé. Comparé à Piwigo, on passe de la complexité à la simplicité en très peu de temps.

Par contre, ça manque de finitions: la localisation laisse à désirer, même en fr, et les vidéos déjà en webm ne sont pas centrées.

La source de cette information, me concernant, ça a été les utilisateurs qui avaient mis à jour.

Ils ne pouvaient plus utiliser l'applet et ils avaient droit à ce message dans la console:

 Missing Application-Name manifest attribute for: https://xxx/path/to.jar
 Plug-in Java 10.51.2.13
 Utilisation de la version JRE 1.7.0_51-b13 Java HotSpot(TM) Client VM

Merci pour cette remarque. J'aimerais bien mettre à jour le journal, mais il semble que je ne puisse pas le faire…

oss-compat ne marche qu'avec un noyau linux supportant les modules oss, ce qui n'est pas le cas du noyau Ubuntu…

Ça peut être intéressant, mais le problème est surtout sur la restauration, beaucoup plus que sur la sauvegarde. La commande mysqldump mets moins de 2 minutes sur une base de 10 Go, c'est tout à fait acceptable.

J'avoue que j'ai toujours un peu peur de la restauration d'une base au format binaire. Ça peut donner l'impression de marcher, mais je ne sais pas jusqu'à quel point on peut avoir confiance en elle. Si le snapshot se fait au mauvais moment, on est susceptible d'avoir un sympathique "table marked as crash" lors de la restauration, et d'avoir à faire un REPAIR TABLE qui peut prendre beaucoup de temps (!).

Enfin, en ayant un fichier par table, on gagne la souplesse de pouvoir éventuellement restaurer que la table fautive (si l'applicatif le permet). Sur de gros volumes, ça peut se révéler très utile.

Je confirme. Je l'ai mis dans mon script, mais je ne peux pas éditer mon journal.

Ce n'est pas nécessaire si on sauvegarde la table "mysql", normalement.

J'ai utilisé Piwigo pour héberger nos photos sur différents événement, et ça c'est toujours très bien passé. Le logiciel est bien conçu, bien pensé et simple à utiliser. On peut mettre en place un site personnalisé et joli très rapidement.

J'ai beaucoup apprécié le fait que le client lourd de téléversement d'image soit disponible sur les distributions Linux :).

Le seul point où j'ai vraiment buté concernait les vidéos. Il n'est plus rare que les appareils aient une fonction vidéo, qui est de plus en plus utilisée. Certains téléphones prennent même des vidéos en 1080p (!) J'aurais aimé pouvoir les mettre à côté des photos. J'ai fini par y arriver, mais ce n'était vraiment pas simple et j'ai du utiliser mes compétences en développement.

C'est d'autant plus dommage qu'avec la balise video, c'est devenu beaucoup plus simple de gérer cet aspect là.

J'espère qu'un jour Piwigo pourra évoluer et devenir un logiciel de création de galerie multimedia.

\o je connaissais pas. Il a effectivement l'air un peu plus abouti. Merci :).

D'après le site des appels d'offre :

"Le marché est déclaré sans suite pour motif d'intérêt général"

Ça n'aura pas duré longtemps cette annonce ...

C'est une façon de le voir.

En fait, les gens de Linagora publient avant tout sur internet pour eux, afin de ne pas perdre la connaissance qu'ils ont acquises. On retrouve toujours quelque chose qui est sur internet, on perd de temps en temps ce qui est sur un disque dur.

La raison pour laquelle certains de ces articles sont LinuxFr est parce que nous avons, à Linagora, un esprit de partage. Au lieu que ce soit que les xxx personnes de Linagora, les lecteurs de LinuxFr peuvent aussi en profiter. Ce sont des articles techniques sur des solutions techniques, qui ne sont pas développés par Linagora. Ils ne sont pas écris par des commerciaux et n'ont pas vocation à décrire les offres de cette société.

Tant mieux pour toi si tu sais déjà toutes ces choses et si tu connais déjà un meilleur outil que celui là. Mais vu les autres commentaires, il est clair que tout le monde n'a pas ton niveau ou ton approche sur le sujet. Ça permet également d'en discuter à travers les commentaires.

Je suis personnellement content que l'un de mes collègues ait pu augmenter le contenu et la qualité d'un site communautaire comme linuxFr. Ça fait quand même quelques années qu'on en profite avec très peu d'articles à notre actif, je suis content que ça puisse désormais changer.

Mais si tu crois que Linagora est une société d'édition ou un site de presse, libre à toi.

Alors, 70 % du budget informatique représentant 50 millions, ça fait un budget total d'environ 71,4 millions d'euros depuis 2004. Ça veut dire que leur budget informatique sur 5 ans est passé de 71 à 21 millions d'euros grâce au passage à Linux, une économie de 70%.

Depuis 2004, il s'est écoulé 5 ans, ce qui nous fait 50 000 000 / 15 000 / 5 =~ 666 euros par license Microsoft pour le pack Windows + Office, avec support inclut.

Pour info, l'ordre de grandeur est le même à l'Assemblée Nationale, 500k€ en moins sur un budget de 800k€, ça nous fait 62 % d'économie.

PS: Les mauvaises langues diront que le prix de Microsoft Windows + Microsoft Office forment le nombre du démon :).

Ça se marie aussi très bien avec OBM. La rumeur affirme que certaines vidéos de nos chers députés sont passés en aout dernier sur lemondeinformatique vantant, entre autres choses, les mérites de cette synchronisation des pda. Cette même rumeur affirme que la solution derrière est basée sur le triplet gagnant funambol, obm et thunderbird.

Mais tout ça n'est que rumeur, bien entendu ;).

Doit on mettre sous licence proprio tous les softs libres qui tournent sous Windows sous prétexte qu'il sera après difficile de les faire basculer sous Linux ?

OBM n'a pas vocation à faire basculer les gens sous Linux ... C'est juste un groupware libre, s'appuyant sur des technologies libres et qui tient bien la charge face à ces vils et nombreux utilisateurs.

mode troll enclenché

Comment cela serait-il possible si la version win de OOo était pas libre et payante ?
Sun gagnerait des sous avec sa suite et pourrait embaucher des développeurs au lieu de réduire les équipes ?

Et si OOo ne supportait les .doc que dans un plugin pas libre et proprio ?
Les clients arrêteraient de nous demander le format .doc / défaut, ce qui aurait pour heureuse conséquence d'avoir des utilisateurs qui n'auraient plus peur de ne pas retrouver leur document après avoir cliqué sur sauver ?

Non mon avis est que vous mettez d'abord vos intérêts en avant.
ouh ouh, les vilains développeurs d'OBM, pendez les : ils essaient de vivre de leur travail en faisant du logiciel libre ouh ouh. Pire encore, ils sont capitalistes, pensez donc, ils mettent leurs intérêts en avant ouh ouh. Nan c'est vrai quoi, si on fait du logiciel libre, il faut le faire dans une cave, bénévolement, nourri via le soupirail au pain sec et à la kro.

mode troll désactivé.

la philosophie du libre, c'est que tous les logiciels soient libres, même un connecteur ou une application qui intéragit avec un contenu proprio.

Celle là, elle est sévère.

Tu utilises du proprio ? ben tu as à droit à la façon de faire du monde et des éditeurs proprio : non seulement tu dois payer avant d'entrée mais en plus tu seras privé de tes libertés et enfermé chez la société éditrice. De toutes façons tu as l'habitude, ça te changera pas trop.

Tu utilises du libre ? no problemo, connecteur libre, sources libre, tu bénéficies directement des nombreux avantages du concept. Tu peux même développer le tien sur ton client de courriel préféré de triffouilly les oies qui ne fonctionne qu'avec la lib caca sur s/390 ? pa ni problem, le code source du connecteur Tbird est assez succinct, tout se passe côté serveur, tu pourras faire ou te faire faire le connecteur kivabien (tm).

OBM propose tout simplement une offre complète, libre et qui s'adapte à la philosophie et aux usages de ses clients.

Quand ses clients utiliseront tous KMail ou Évolution, et bien ma foi, la question ne se posera plus ;).

Si ca vous fait chier de proposer le support Outlook et préférez vendre une solution "complète" client/serveur, ben ne proposez pas le support Outlook.

J'adore cette phrase. Comment tu fais pour proposer vendre une solution "complète" sans support Outlook ? C'est le seul client de messagerie fournie par défaut sur 95% des machines. Tu ne le supportes pas, tu n'as rien à proposer, tu n'existes pas, tout simplement.

En tant que contributeur à Go-OO et non employé par Novell, je crois que je vais sauter à pied joints dans le troll.

Go-OO n'est pas un "produit" Novell, contrairement à la "vrai" suite made in Sun, tout le monde peut y contribuer.

Les distros intègrent tout (Mandriva, Ubuntu, Debian, Suse, Ark, Pardus, Gentoo) ou partie (Fedora, Red Hat) de Go-OO. Elles ont chacune des raisons qui leur sont propres, mais le fait que l'ensemble de ces développeurs sont sous Linux ne doit pas y être étranger. C'est la seule version ou dans le ./configure on peut sélectionner sa distribution, et les autres paramètres se remplissent tout seul en fonction.

C'est la seule version d'OpenOffice.org développée par des linuxiens pour des linuxiens avec des technologies liées. Certains de mes patchs sur l'intégration kde ou gnomevfs ne peuvent ainsi pas être reversé chez Sun : ce code n'existe pas du tout dans la version vanilla.

Enfin, si Go-OO est si peu promu, si personne n'en entend parler, c'est aussi parce que c'est une volonté des initiateurs du projet. L'idée est essentiellement de montrer par l'exemple comment un projet libre peut et doit se dérouler pour qu'il marche. Ce n'est pas de forker la version vanilla, il y en a déjà bien assez comme ça (OxygenOffice, NeoOffice, BrOffice, Symphony, Red Flag Office, ...).

On ne peut pas gérer le processus par mail. Ça fait partie de la roadmap.

On s'inspirera probablement de RedMine, qui l'implémente déjà de façon très complète.

Il y en a beaucoup, je vais essayer de rester succinct.

Dans ce qui va pour OTRS :
* Tosca n'a pas de workflow paramètrable
* Tosca ne supporte pas la réception d'emails
* Tosca ne fonctionne qu'avec MySQL
* Tosca n'a pas de jouli calendrier En fait si, depuis quelques heures, Tosca a un très joli calendrier dans ses outils d'administration !

Évidemment, on compte bien combler ces lacunes, RoR intègre nativement le nécessaire pour y répondre.

Dans ce qui va pour Tosca :
* OTRS n'utilise pas de framework de développement, ce qui pose plein de problèmes pour les questions d'évolution énoncées dans les commentaires précédents.
* OTRS n'a pas de système de plugin, il est donc plus difficile de l'adapter à ses besoins. Et encore plus difficile de conserver ses adaptations lors d'une montée de version. Un exemple d'actualité très flagrant est la migration d'un bugzilla modifié.
* OTRS semble assez pauvre en reporting : pas de camemberts, pas de barre de progressions, pas d'alertes sur des CNS en cours de dépassement
* OTRS semble dur à utiliser au quotidien : pas de vue comme celle des "demandes à traiter", qui permet instantanément de savoir ce que l'on a faire au quotidien. Tous les commentaires sont affichés lors de la consultation d'une demande : une hérésie totale quand on en est à notre 9ème commentaire de la journée.
* OTRS n'a pas des notions comme le périmètre d'un client (ses logiciels), les compétences des intervenants, les vms utilisées pour ce client, la gestion d'étiquette pour regrouper un paquet de demandes ou la notion de crédit-temps, lorsque l'on facture un client au compte-goutte.
* OTRS n'a pas d'AJAX : il n'y a pas de champs dynamique, d'adaptation du logiciel au profil de l'utilisateur ou de petits effets. En conséquence, son interface peut paraitre surchargée.

Pour voir les autres concurrents, libre ou non, wikipedia est là :
http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_sy(...)

Je n'ai pas connaissance d'ERP libre digne de ce nom. Par ailleurs, les quelques clients qui m'ont parlé de leur ERP étaient tous d'accord sur un point : c'est une horreur dont ils aimeraient pouvoir s'extirper.
Vous semblez avoir une meilleure expérience, ceci dit ;).

Par ailleurs, Tosca utilisant Ruby On Rails, il parle nativement le R.E.S.T. et (le) faire communiquer avec d'autres applications sera assez simple (comparativement à ce qu'il aurait fallu faire avec SOAP, XML-RPC & Co). Il est d'ailleurs question devant certaines machines à café bien placées de le relier à OBM, pour pouvoir facturer directement depuis Tosca.

Enfin, j'ai du mal à voir en quoi utiliser un outil adapté est risqué. Si un jour on doit migrer, il y a de très bons ETL qui nous permettront de le faire. Et si on doit faire une jonction, ma foi, elle ne devrait pas être trop différente de celle avec les bugtrackers communautaire.

On a développé cet outil from scratch car aucun de ceux que nous avons consulté ne répondait à nos attentes. Il y a 2 ans et demi, OTRS n'en était pas où il était. Et même maintenant, sa vision n'est pas assez complète pour répondre à nos attentes. La dé-corrélation entre les différentes interfaces peut aussi poser de nombreux problèmes.

Ne connaissant pas trop les ERP, ma réponse risque de ne pas convenir.

Pour l'instant, on a utilisé cet outil sur des logiciels ou des offres que nous ne développons pas nous même. On les a intégré, amélioré, configuré, adapté, reversé, etc, etc, mais on ne les a pas forké. Le logiciel continue dans son coin, sur ses outils propres, et donc ce problème de doublon ne s'est pas posé.

Sur les logiciels que nous développons nous même, comme OBM ( http://www.obm.org ), la question ne s'est pas non plus posée.

Il faut bien voir que ce sont 2 systèmes bien différents. Ce ne sont pas les bugs déposés par les clients qui guident le développement d'un projet mais bien son équipe. Par ailleurs, la plupart des demandes concernent une façon d'utiliser le logiciel ou l'influence de son contexte.

Peut-être que vous avez raison dans d'autres contextes ou d'autres utilisations, mais pour nous, ce n'est vraiment pas une "horreur à gérer" et bien plus un "raaaaaah qu'est-ce que c'est cool de pouvoir y passer si peu de temps".

Les commerciaux adorent être prévenus des dates de renouvellement.
Les ingénieurs adorent le fait de ne voir que les x contrats sur lesquels ils travaillent, ils nous l'ont signalé tout de suite quand la fonctionnalité a régressé sur le serveur de test ;).
Enfin, les manageurs peuvent connaître en un seul écran le flux total de leurs contrats.


Et rien n'empêche de mettre la référence de l'un dans l'autre, si les 2 outils sont utilisés. C'est ce que fait le projet OpenOffice.org avec leur traqueur BugZilla et leur outil EIS. C'est vraiment un développement minime, et que d'ailleurs nous utilisons pour lier les contributions des anciennes demandes à notre ancien mantis.