Larry Cow a écrit 5011 commentaires

Comment disent les québecois : "pas si pire" ;)

Sur de ton coup? Parce que j'utilise assez peu ce genre de fantaisies, mais à chaque fois que je l'ai fait tester à des gens c'est ce qui m'est remonté comme reproche principal (c'était du temps de KDE3, cela dit).

Il vaudrait peut-être mieux un truc tout fait sans wizard avec juste une interface web propre, non? Genre une base debian avec mises-à-jours de sécu automatiques, sans X et avec un webmin amélioré.

N'empêche que les bureaux libres essayent régulièrement de rattraper les fonctionnalités "partagées" de la registry Windows (via Kiosk, par exemple) et sans grand succès. Sans compter que c'est systématiquement limité à un ensemble réduit de programmes (l'environnement de bureau, au mieux).

C'est vrai que la base de registre a été (est encore?) un cauchemar pour tous les utilisateurs "avancés" de Windows pendant des années. Mais j'ai l'impression, vu ce que la concurrence est capable de faire, que c'est plus lié à la problématique elle-même qu'à l'implémentation. Au moins sur les versions récentes (i.e. depuis 2000/XP).

Un bon coup de peinture et c'est parti.

Pimp my minitel!

Sans aucun port _tcp_ ;)

L'interaction avec un groupware costaud et synchronisable sans douleur avec la plupart (sinon tous) des PDA et PDAphones du marché.

En tant que client isolé, TB est bien meilleur qu'Outlook (présence d'extensions sympa, respect des standards, etc). Par contre, dès qu'on l'utilise en entreprise, c'est beaucoup moins rigolo. Sous Outlook+Exchange, tout se fait sans effort. Avec TB, faut tout bidouiller.

Si tes besoins de messagerie d'entreprise se limitent aux e-mails (sans carnet d'adresse partagé ni rien), alors là oui, effectivement, Outlook est totalement inutile : un simple serveur IMAP bien foutu et roulez jeunesse. Si tu veux rajouter des calendriers dessus, tu peux encore t'en sortir (extension Lightning + serveur WebDAV), mais oublie l'authentification centralisée : faudra user et abuser de l'enregistrement de mot de passe dans le client mail ou bien te résoudre à taper le-dit mot de passe quinze fois par jour.

Si tu veux rajouter le carnet d'adresse, le premier réflexe (salutaire) c'est LDAP. Normalement, si tu as bien fait ton boulot et que calendriers et boîtes mail ont la même base de mots de passe, il y a de forte chances que tu aies déjà un annuaire quelque-part. Sauf que le support de LDAP sous ces clients (TB en particulier), c'est read-only, et schéma figé.

Si tu es prêt à n'avoir que des clients sous Linux, tu peux effectivement éviter TB et passer sur du évolution ou kmail. Mais ceux-ci ne sont pas exempts de problèmes non plus. Evolution a le gros avantage de converser avec Exchange, et le gros inconvénient (à mon gout) d'être complètement gnomesque. Donc j'admets ne pas l'avoir testé à fond depuis longtemps (surtout avec des Macs dans les pattes et un support de Gtk+ sur Mac complètement foireux). Normalement, le pépin "Mac" devrait être assez rapidement de l'histoire ancienne vu le portage natif de Gtk (bon, c'est toujours aussi laid et mal intégré graphiquement, mais au moins on n'a plus besoin de X).

KMail (enfin Kontakt, pour être précis), par contre, se synchronise pas mal avec un paquet de groupware libres, voire sans groupware (en stockant les données contact/agenda/... dans des dossiers IMAP cachés, compatible avec Kolab). Pour ça, il est franchement bien. Par contre, il est toujours infoutu d'afficher les mails HTML, et ça en entreprise ça ne passe pas du tout. Sauf si c'est ta boite et que tu peux faire jouer le "c'est mail en texte brut ou bien tu prends la porte", mais c'est rare (et assez peu recommandable). Cela dit, c'est censé s'arranger avec les prochaines versions, de ce que j'ai lu.

Bref, même si les choses avançent doucement, c'est loin d'être évident de mettre en oeuvre une alternative libre à Outlook dans le monde professionnel. Beaucoup de gens essayent régulièrement, ça peut convaincre lorsque c'est "suite à rien" comme dans mon cas (i.e. on monte directement la messagerie sur des bases libres), mais c'est totalement illusoire de faire accepter ça comme remplacement à des solutions Microsoft en place. Hélas.

Dans les choses qui bougent bien, il y a OpenChange pour ceux qui veulent faire interagir du Microsoft existant avec du libre ; il y a SOGo (Scalable OpenGroupware.org) qui offre un intégré assez séduisant et visuellement pas trop éloigné d'un thunderbird en version web ; Zarafa, récemment mis en libre, offre une interface web très proche d'Outlook et une synchronisation "DirectPush" native pour les PDAs Windows et compatibles. Bref, il y a des pistes, plein de pistes. Mais le mec qui ne veut pas se faire chier, il se paye un Small Business Server et roulez jeunesse. C'est triste.

Je reviens un peu là-dessus, parce que je me rends compte que j'ai répondu un peu vite.

Par "fédération", je n'entends pas forcément une communication pair à pair intégrale. Plutôt pas, même. Je crois davantage à un multitude de "petits centres", en réponse au modèle actuel (peu de "gros centres"). Et en ce sens, l'approche prônée par SMTP ou XMPP me paraît assez saine : des noeuds mis en place et maintenus par les compétences "locales" (le service informatique d'une entreprise, une association, un grand frère pour une famille, etc.). Ces noeuds communicant entre eux pour fournir un service le plus proche possible des services centralisés actuel. À quelques détails près (les RBL qui listent les IPs résidentielles comme "invalides", notamment), c'est déjà/toujours complètement possible pour l'e-mail, et pour l'IM si on accepte de faire une croix (temporairement, j'espère) sur les aspects multimédia.

En gros, Jingle/SIP ne me paraissent utiles que pour une fraction des applications. Le reste, c'est à un réseau semi-centralisé qu'il revient.

Oui, mais avec Jingle XMPP a(ura) exactement la même chose. Et XMPP a déjà tout ce qu'il faut pour dialoguer avec le monde HTTP (BOSH, notamment). La convergence ultime en quelque-sorte :p

Tu devrais aller voir du côté de autonomo.us, ils ont eu quelques réflexions sur les outils à utiliser dans ce genre de cas, et je pense qu'y participer (c'est en anglais) pourrait t'aider à trouver ce qui te convient.

En ce qui me concerne, je triche (je suis sur une dédibox et pas directement chez moi), mais j'essaye de garder à l'esprit ce côté "j'héberge moi et les miens". Pas de webmail trop sexe pour le moment (juste un horde tout bête), par contre du ejabberd + jwchat c'est assez appréciable. Je propose des bookmarks partagés avec semanticscuttle et de la lecture de flux avec tt-rss. Pour le reste, c'est assez variable. J'ai eu des blogs, j'ai eu du "profil en ligne" à la noserub. Je lorgne pas mal du côté de buddypress (surcouche à wordpress-mu permettant de "singer" un réseau social sur fond de blogging) et de Elgg.

J'essaye de suivre de très près tout ce qui a trait à la fédération de serveurs, parce que je si je reste persuadé de l'importance de décentraliser tout ça, je ne suis pas prêt non plus à pouvoir me passer des communications entre nœuds. J'ai d'ailleurs de plus en plus le sentiment que la vraie clé du problème se nomme XMPP, mais je rêve peut-être un peu.

Oué, il paraît que c'est rien d'autre qu'une grosse bande d'illettrés. Oué mon journal.

Ah bah si. Un process bien conçu sous DOS, il a toutes les chances de mieux tenir qu'un process mal conçu sous Linux. Voire qu'un process bien conçu sur un Linux classique (non RT), puisqu'il encourt le risque de voir un autre process foutre la merde.

Bref, gnome pompe pas vraiment macos. Ou alors de tres loin.

Ce qui laisserait penser que MacOS en a une immense. Soyons sérieux.

la bonne vieille méthode du fork est tout aussi valable.

Largement, pour moi. Autant les threads sont rapidement incontournables quand on vise la réactivité (l'approche BeOS d'avoir un fil d'exécution par fenêtre, ça serait ingérable avec des fork()s). Par contre, pour des traitements "lourds", fork()er reste bon marché. Et beaucoup plus "simple" à implémenter/débugguer (bon, c'est pas tant le fork lui-même que les algos utilisés dans ce genre de cas).

Pour de la bureautique de base, l'utilisateur va tout naturellement utiliser plusieurs programmes distincts (de très nombreux, même, vu la tendance actuelle) qui sauront tout à fait se répartir entre les coeurs.

En fait, j'ai du mal à voir où est le problème, je crois.

Dans tous les cas, il faut prévoir ta communication. Dans les exemples Python que j'ai vu, c'est essentiellement utilisé pour travailler sur des beaux gros vecteurs (allez hop, on coupe la liste en 4 et on file ça aux quatres coeurs, roulez jeunesse). Pas besoin d'avoir un doctorat pour faire ça, il me semble. Et c'est aussi "lourd" en threads qu'en process, pour des données suffisamment grosses.

Les langages comme Python avec des implémentations totalement foireuses du multi-thread se font largués.

C'est vrai que le GIL - qui dans un contexte mono-coeur était une foutue bonne idée - prend des airs de boulet rouillé dans ces conditions. Ceci dit, le module multiprocessing de Python2.6 (installable dans Python2.5 pour ceux qui veulent) limite sensiblement la casse.

http://openidenabled.com/php-openid/

J'avais essayé SQLite mais c'était limité à la version 2 chez Free autant qu'il me souvienne. Bref ! Je n'en étais pas satisfait car trop limité par rapport à MySQL.

Limité par rapport à MySQL, oui, mais par rapport à des fichiers textes?

Strange game...

Franchement, chapeau. J'ai eu exactement le même besoin il y a quelques mois, mais ça a terminé sur Blogspot (aussi parce qu'on ne m'a pas trop demandé mon avis (probablement parce qu'on ne voulait pas trop l'entendre)). J'ai été faible. Toi pas. Chapeau.

Maintenant, on va essayer d'être constructif. Et par "constructif", j'entends "potentiellement désagréable".

* Déjà, méfiance chez les hébergeurs gratuits, et en particulier chez Free. Normalement, ton site _doit_ avoir une partie "publiquement accessible" conséquente s'il ne veut pas se faire bloquer sans autre forme de procès. Dans ton cas, Poupitchi est dans un sous-répertoire, mais ça peut poser problème si l'utilisateur ne fait pas gaffe.

* Éviter d'avoir à configurer un accès SGBD, c'est louable. Mais vu que même les hébergeurs à la Free supportent SQLite, quel avantage y a-t-il à éviter les BD en mode "fichier"? Rien que pour les accès concurrentiels, ça devrait te simplifier la vie.

* Même si c'est un peu moisi chez Free, remplacer le login/pass par un accès OpenID serait un gros plus, je trouve. Au moins dans mes cercles où presque tout le monde en a (au moins) un. Pas d'inscription automatique non plus, mais l'admin pourrait rentrer un OpenID au lieu du couple login/pass. Ça éviterait la transmission (hors canal) de données sensibles, notamment.

Même avec du libre. Qui te prouve que le compilo est réglo? Le fait d'avoir ses sources. Mais qui te prouve que ces sources sont bien celles qui ont construit son binaire? Le fait d'avoir ses sour

Ah ben je croyais que les banques n'avaient francaises pas besoin de l'Etat qu'elle s'en sortaient bien toute seule.

Respire, respire ;)

un mec qui prie exclusivement plusieurs dieux uniques

Et vice-versa ;)

Bah oui, mais pas à _bien_ trader. On en revient toujours au problème de l'intéressement.

Un compromis pas idiot - me semble-t-il - qui était notamment défendu par Shuttleworth consistait à "geler" les primes de traders pour un certain nombre d'années. Si tout va bien, tu touches ta prime normalement à la fin du gel (pour M. Ubuntu, une durée de 7 ans). Si tout va pas bien (grosse crise monétaire internationale, au hasard), ta structure bénéficie des primes gelées pour combler la brèche.

Ça aurait en outre l'avantage de décourager les comportement "après moi le déluge" (pour les remplacer par du "après moi +7 le déluge", mais c'est déjà une amélioration).

Cela dit, la boîte tu as le droit ne pas la monter tout seul. On a tous des potes (qui ont été) en école de commerce, autant qu'ils servent à quelque-chose ;)