Depuis plusieurs mois, nous avons quelques postes de travail sous Linux dans l'entreprise où je travail. Je dois avouer que ça fonctionne plutôt bien après quelques temps d'adaptation et que je suis bien satisfait du résultat de notre déploiement Linux.

La distribution utilisée est Ubuntu en version 7.10 et 8.04 (au départ on a commencé avec la version 7.04). Je parle de plusieurs mois, mais en fait, ça fait pratiquement un an que le premier poste Linux a fait son entrée dans le parc informatique! Avec le temps, quelques autres se sont rajoutés.

Le bogue récurant qu'il restait depuis tout ce temps était l'accès aux partages Samba de différents serveurs de fichiers de l'entreprise. L'environnement de bureau est GNOME et l'accès aux partages réseau se fait donc normalement à l'aide de GnomeVFS ou GVFS, dépendant de la version d'Ubuntu. Autant un que l'autre, c'est instable et pas fiable au pas possible.

Avec GnomeVFS et GVFS, on a souvent le droit au message "Impossible d'afficher le contenu complet de ce répertoire". Un ou quelques rafraîchissements plus tard, le contenu du répertoire s'affiche enfin. Pas bloquant, mais très dérangeant pour l'utilisateur. Un autre problème, l'usager ouvre un fichier (par exemple dans OpenOffice), fait des modifications et tente d'enregistrer. Bang! Fichier non accessible... rien à faire à part un copier/coller dans un autre document pour ne pas perdre les modifications...

GVFS est encore pire. GVFS est tout simplement pas prêt à être intégré dans une distribution "stable". Bien souvent, il refuse tout simplement de monter les partages demandés.

La solution jusqu'à tout récemment était de monter les partages réseau avec des bêtes scripts en utilisant l'utilitaire mount et le module cifs du kernel (paquet smbfs). Bien que fonctionnel sans aucun bogue, c'est pas très pratique étant donné que je dois paramétrer d'avance les partages dont aura besoin l'utilisateur. C'est aussi pas bien adapté à une machine multi-utilisateurs où chaque utilisateur a son propre code d'accès.

Il y a quelques semaines, j'ai donc développé une application bien simple : un frontend graphique à l'utilitaire mount. Avec cette application, j'obtiens donc les avantages de *VFS (accès simple et rapide, sans configuration préalable par un technicien) sans ses bugs.

Mon employeur m'a permis de distribuer cette application sous licence GPLv3 afin d'en faire profiter d'autres à l'extérieur de l'entreprise. Donc, si vous aussi vous avez des problèmes avec l'accès aux partages de fichiers, cette application peut vous être utile !

Plus d'infos et téléchargement : http://www.ti-quebec.com/linux-unix/monter-un-partage-samba-(...)

> Lire le journal (43 commentaires, moyenne: 2,7).

Hello,

Depuis quelques semaines, je cherche une solution de remplacement pour nos formulaires électroniques utilisés à l'interne. Nous utilisons depuis plusieurs années MSO (surtout Excel et un peu Word avec quelques macros (très) basiques) pour développer nos formulaires.

Oui, je le sais, ce ne sont pas du tout des logiciels pour faire des formulaires, mais c'était une solution simple à mettre en place et qui marchait bien jusqu'à maintenant.

Notre parc informatique est devenu très hétérogène avec le temps avec des postes Mac, Windows et depuis quelques temps Linux a aussi fait son apparition chez quelques usagers. Il est donc important que la lecture (et le remplissage du form) soit possible sur ces 3 plateformes. Pour la création du formulaire, ce n'est pas très important même si ça serait souhaitable.

Premier problème avec notre solution actuelle, Microsoft a eu la bonne idée de supprimer le support VBA (qui était déjà très limité sur Mac) de MSO 2008. La cohabitation Windows/Mac qui fonctionnait bien jusqu'à maintenant est compromise avec ce changement. Garder tout le parc informatique Mac en MSO 2004 n'est pas une solution, car il souffre de gros problèmes de performances sur les Mac Intel.

Deuxième problème, MSO et OOo ne traite pas les champs de formulaire de la même façon (entre autre pour désigner les composants d'un groupe de boutons radio). Il est donc impossible de faire cohabier MSO et OOo, sans devoir faire 2 versions des formulaires.

Bref, il faut se tourner vers autre chose.

La première solution qui m'est venu en tête, c'est d'utiliser des documents PDF avec des champs éditables. Mais j'ai pas trouvé de logiciels simples à utiliser par un non-technicien. Je me suis perdu à quelques reprises sur le site de Adobe, mais j'ai tourné en rond plus qu'autre chose. J'ai essayé le support xform de OOo avec l'export PDF, mais ce n'est pas du tout concluant.

La seconde solution serait d'écrire une application Web et de stocker l'information dans une base de données. Le problème, c'est que ça prendrait un technicien à chaque fois pour designer un formulaire. Pas pratique.

Autres suggestions ou je suis condamné à tourner en rond éternellement ? ;)

> Lire le journal (19 commentaires, moyenne: 2,8).