l'affichage des documents en html se fait sur toute la largeur disponible, or sur un grand écran c'est très pénible à lire. LaTeX fait naturellement des grandes marges pour cette raison ; vous devriez limiter votre largeur de ligne.
Bof... en faisant ça, tu enlèves du pouvoir (je n'ose écrire « de la liberté » copyright FSF) à l'utilisateur. Le choix de la Poule lui permet de régler la largeur de sa page comme il le désire. S'il veut voir le texte sur toute la largeur de son 24 pouces, il peut (ça permet notamment de faire ressortir l'organisation d'un chapitre en paragraphes) ; s'il préfère avoir une largeur semblable à un livre (comme tu le préconises), il réduit la taille de sa fenêtre.
Et rien n'a été imposé, tout a été proposé (copyright Siroz pour les connaisseurs).
Au fait : LaTeX fait de grandes marges certes pour la lisibilité mais aussi parce qu'il s'appuie sur les standards américains de la mise en page. En utilisant KOMA-Script, on peut accéder aux standards européens avec des marges notamment réduites.
Merci pour toutes tes réponses. Ça m'a vraiment donné envie d'essayer Nuxeo RCP et de le montrer à mes collègues chargés de communication (et documentalistes, je crois que ça pourrait vraiment les intéresser pour développer un portail documentaire).
Petit indice : les points de suspension peuvent être utilisés pour indiquer un sous-entendu dans la phrase précédente, ou comme marque d'ironie. Mais que faisais-tu pendant les cours de français ? ;-)
à l'origine, le langage « SMS », ce n'est pas pour taper plus vite (après tout, les SMS ne sont pas de la messagerie instantannée) mais pour économiser de la place sur le message à envoyer
Je n'oppose pas les deux raisons, elles sont sans doute justes l'une et l'autre. Je crois que le langage SMS continue d'évoluer, notamment pour encore accélérer la vitesse de frappe (le dictionnaire automatique est une autre manière d'accélérer la frappe, mais c'est un autre usage, concurrent, avec peu de valeur ajoutée pour les utilisateurs habitués au langage SMS).
Ensuite, y a le langage « SMS » porté sur IRC, MSN et consorts. Là encore, ils plaident la rapidité d'écriture.
Je suis d'accord, l'argument ne tient plus hors des messages envoyés par un téléphone portable. Ils feraient mieux d'acheter un Dvorak...
C'est leur argument qui est incorrect dans ce cas (« je fais du SMS dans MSN pour taper plus vite.») Mais ça ne veut pas dire que c'est MAL de faire du SMS via ces médias : c'est un mode de communication différent... Je n'arrive pas à avoir un jugement moral sur cette manière de faire.
Mais s'il y a bien une chose que les IM et les SMS ont pourri, c'est l'écriture !
Je ne vois pas trop le rapport de cause à effet. Il y a les SMS et le langage SMS, et il y a le français. Le langage SMS, ce n'est pas du français, c'est un nouveau dialecte, voilà tout. Il existe pour pas mal de bonnes raisons (taper plus vite sur un clavier à 9 touches de 10 cm de côté) ! Alors OK, si tu lis un SMS en mettant en route ton analyseur grammatical de français, ça va le faire hurler. Mais est-ce que c'est grave docteur ? Je dirais non, vu que le langage SMS est lu par ceux... qui l'écrivent couramment ! Ils communiquent, c'est kikoo-lol et tout le monde est content.
Que les professeurs de français ne soient pas satisfaits parce que le niveau en français baisse, je le comprends. Mais qu'ils incriminent les nouvelles technologies, franchement, je ne vois pas le rapport. En tout cas il n'est absolument pas prouvé. On peut lire La redocumentarisation du monde de Roger T. Pédauque, pour voir que plusieurs pédagogues commencent à réfléchir (depuis 10 ans) à l'impact des nouvelles technologies sur la lecture. Par exemple : peut-on lire sur écran ? Ou alors : est-ce que l'acte de lecture change maintenant que les acteurs numériques sont à la fois lecteurs et écrivains ? C'est assez passionnant, mais le champ d'étude en est encore à ses balbutiements.
Dernière petite remarque sur l'orthographe : à quoi ça sert ? Principalement à être sûr que l'autre comprendra bien le message, de manière non-équivoque -- d'ailleurs lorsque je reçois une lettre écrite en français complètement pourri orthographiquement, il m'arrive parfois de douter du sens de certaines phrases ! Et là, c'est la communication qui est coupée !
C'est exactement le même but qui est poursuivi par la typographie (majuscules accentuées, ponctuation, etc.) Malheureusement les défenseurs de ces normes oublient ce côté pratique pour ne voir que le combat contre les infidèles^Wmauvais en orthographe. Ce n'est pas comme ça qu'ils vont les convaincre.
bah c'est juste que sur les deux c'est toi le kikouloleur.
LOL
Bon, il y a quand même des indices de ma vieillesse... par exemple lorsqu'il me regarde avec des yeux écarquillés en hurlant : « Non, attends, tu as joué à Myst 1 à sa sortie ??? Et à Alone in the Dark 1 ??? Sans émulateur ??? »...
3615 MyLife : ça fait quelques mois que je ne suis plus « la plus jeune génération » dans mon environnement professionnel. J'ai amené pas mal de technologies de natifs numériques dans ma boîte, comme la messagerie instantanée (Jabber), ce dont j'étais super fier... jusqu'à la relève : il a 20 ans, il a 3 téléphones portables qui discutent entre eux comme des Tamagotchis, un réseau d'entreprise chez lui avec 50 PC refroidis par le circuit d'eau potable, youpi que j'me dis, on va parler la même langue.
Résultat :
- Trois Singes : Hé, viens voir notre serveur Jabber, c'est super pour travailler en synchro avec le wiki, le téléphone, gna gna gna taxonomies populaires, gna gna gna web 2.0, gna gna gna révolution des usages.
- Beau gosse de 20 ans : bof bof, Jabber j'aime pas, moi mon truc c'est l'IRC.
Merci pour la réponse qui a dû vous prendre un peu de temps libre :-)
Je comprends mieux l'opposition que vous faites entre client riche (RPC) et client nouveau-riche (Ajax) ; opposition qui concerne clairement les usages actuels de ces deux méthodes. Le fait que vous vous placiez « dans le cadre de gens qui ont besoin de gérer beaucoup d'information en même temps (y compris sur plusieurs écrans) » est pour moi beaucoup plus clair que lorsque vous écrivez « fournir des fonctions ou une interface utilisateur plus riches que ce qu’on peut réaliser avec les technologies de clients légers ».
Le développement d'interfaces utilisateurs en client riche Java (qu'on utilise les techno Eclipse RCP, autrement dit SWT/JFaces ou les technos Sun comme Swing) reposent sur des concepts qui sont maintenant connus et maîtrisés depuis des années, alors que les interfaces riches en client Web (autrement dit Ajax) sont encore toutes récentes (2-3 ans), avec un foisonnement de bibliothèques et un outillage (support des IDE) encore moyen.
Je ne peux que confirmer ce point. Nos développements Ajax sont effectivement encore plus proche de l'artisanat que de l'industrialisation -- ils sont grisant mais coûteux. Ajax est une rustine qui se colle sur les technologies^Wstandards du web, c'est à la fois bien et mal : bien parce que ces standards sont d'une haute qualité sémantique (attention, je n'ai forcément pas dit technique...) et parce que, à terme, ils permettent un déploiement d'application bien moins cher que des interfaces riches comme Nuxeo : pensez donc, l'architecture web est déjà en place depuis 15 ans ! Mal parce qu'une rustine, ça se décolle, c'est pas facile à fabriquer, il y a 50 méthodes différentes, pas pérennes...
Donc, avec Ajax, développement difficile mais déploiement pas cher... et j'ai l'impression qu'avec les technologies Java, une fois passé le cap de l'apprentissage, c'est l'inverse.
C'est alors l'utilisateur qui départagera, selon l'expérience qu'il veut vivre (et ça rejoint totalement le début de mon commentaire, waow, je devrais écrire plus souvent à 1H20 un dimanche matin). Ça va être passionnant.
Au fait : est-ce que vous avez jeter un œil sur XUL, qui pourrait être un compromis intéressant ? Je crois d'ailleurs que le back-office du journal Le Monde est codé en XUL, ce qui fait un parallèle intéressant avec l'AFP.
un moyen de développer des applications métiers dont le coût de développement est justifié par le gain de productivité des personnes qui vont utiliser l'application, par rapport à une approche client léger (qui a elle même son coût de développement, d'ailleurs, et qui n'est pas forcément moins élevé).
C'est justement ce dernier point que j'aimerais voir éclairci. Qu'est-ce qu'un « gain de productivité » ? Pourquoi un coût « pas forcément moins élevé » ? Ce n'est pas du tout une critique de Nuxeo (qui a l'air prometteur) mais plutôt une critique du discours : quels sont les arguments qui démontrent clairement des coûts équivalents et un gain de productivité ?
Effectivement, la gamme actuelle de logiciels Nuxeo ne s'adresse pas aux boutiques (DSI ou intégrateurs) exclusivement PHP ou .NET.
Oui, mais ces boutiques-là devraient pouvoir sortir de leur logique pour voir ce qui se fait à côté. Or Java, c'est très intimidant pour eux. C'est pourquoi je m'étonne que vous ne vous adressiez pas plus à cette communauté, un peu comme Apple qui fait pas mal de bruit autour des switchers ;-)
Fonction publique ici aussi : onduleurs avec batterie (je ne sais pas si ça s'appelle comme ça), qui permettent de faire tourner l'ensemble du parc informatique branché sur le courant ondulé (tous les serveurs, 50% des PC des utilisateurs, et sans doute quelques bouilloires :-/ ) pendant 20 minutes. Le temps d'appliquer les processus d'extinction des machines.
Puis une semaine pour tout rallumer, changer les alimentations qui ont cramé, décoincer le NAS qui est parti avant LDAP, etc. :P
La solution me semble un peu compliquée. Quelle distribution utilises-tu ? Pour Debian, je me souviens d'une méthode assez efficace utilisant libpam-chroot :
Doit sans doute être applicable à d'autres distributions.
Une autre possibilité est de monter deux serveurs SSH, l'un qui écoute sur un port non standard (pour les admin) et qui tourne hors chroot, et un qui est chrooté, qui écoute sur le port 22 standard, et qui est fait spécialement pour tes utilisateurs.
Si j'ai un peu répondu à côté, en te proposant d'autres méthodes, j'en suis désolé ;-)
C'est un site qui recense de bien intéressantes interventions. Bravo !
En ce qui concerne la production des vidéos, savez-vous comment ils les ont réalisées ? Notamment pour intercaler vidéo et support ? Est-ce qu'ils passent par une suite logicielle qui « simplifie » le montage, en affichant le transparent dès qu'il change (comme le fait je crois l'association Aristote), où est-ce qu'il y a du montage fait par un bipède ?
Nous essayons de faire ce genre de choses pour automatiser - autant que faire se peut - la vidéo d'une soutenance de thèse ; pour l'instant nous expérimentons SMIL (qui est finalement assez facile à créer automatiquement à partir de plusieurs flux vidéos/images). L'un des inconvénients, c'est que les lecteurs SMIL ne courent pas les rues (Realplayer est presque en situation de monopole ici)...
Pour la diffusion de nos vidéos, la guerre des Flash n'a pas encore eu lieu : nous avons un serveur de streaming (Helix Server et Real Producer, eh non, rien de libre) ; mais nous pensons aussi proposer un lecteur via un lecteur flash, tout simplement parce que le web, de notre point de vue, sert aussi à faire des pages qui incluent esthétiquement texte, image, vidéos, interfaces interactives, etc. comme http://interstices.info/jcms/c_34530/le-tatouage-de-son .
Normalement les établissement publics et les projets libres n'ont pas trop besoin de ce coté marketing (on peut vérifier facilement), paradoxalement le site d'Artenum est bien fichu à ce niveau là en dehors du communiqué de presse.
Rassure-toi, ce discours des « communiqués de presse » n'est pas vraiment pris en compte par les établissements publics. Dans le cas d'un marché public, ils n'ont même pas le droit de les lire ;-) Mais le problème est juste déplacé : les sociétés qui répondent aux appels d'offres sont des spécialistes... de la communication appliquée aux appels d'offres ! Et c'est souvent la meilleur com' qui gagne... encore.
Les petits projets libres, pas ceux tirés par des locomotives de la communication comme Greenp^WMoFo, auraient malheureusement bien besoin d'être marketés puis marketing-communiqués... je ne crois pas à la réussite par les seules qualités intrinsèques de l'outil.
Pour citer Chomsky (bouh, une vile analogie rhétorique) : tout le monde sait bien que les républicains sont de moins bons dirigeants que les démocrates, mais leur machine de com' (je crois qu'il a dit « appareil à diffamer ») est bien trop efficace pour qu'ils perdent la présidentielle.
Pour en revenir au texte d'Earered : belle analyse :-)
En ce qui concerne Nuxeo, et le nuage d'applications qui gravitent autour, je me pose la question du coût de mise en place d'une telle solution. La pile logicielle sur laquelle elle repose peut en effet effrayer les équipes informatiques nourries au LAMP :
- Nuxeo RPC
- Nuxeo EP
- JBoss
- Eclipse (+Ant et Maven)
- Java
- J'en oublie peut-être...
Si le parc logiciel est plutôt basé sur des clients légers (applications web), la migration risque de donner des sueurs froides au DSI, coûter cher en formations, en maintenance, ...
(Je me demande d'ailleurs si Nuxeo n'avait pas déjà pris conscience du problème avant de décider d'abandonner Zope/Python pour JBoss/Java, réduisant déjà l'effet "sueurs froides")
Est-ce que certains d'entre vous ont réussi à mettre en place une telle solution dans leur entreprise de manière pérenne et évolutive ? Est-ce que les solutions concurrentes étaient effectivement plus chères/moins performantes ?
Il me semble que l'UNICODE avait été mal reçu par la Chine et le Japon, pour plusieurs raisons :
- Une raison bêtement technique, qui concerne l'UTF-8 plutôt que l'UNICODE d'ailleurs : coder un texte chinois en UTF-8 prend plus d'octets qu'en BIG-5 ou GB (puisque les caractères codés sur peu d'octets en UTF-8 sont plutôt les caractères occidentaux)
- Une raison "sociologique", beaucoup plus grave du point de vue des asiatiques : le consortium Unicode a en effet considéré que les idéogrammes chinois et japonais graphiquement identiques étaient les mêmes caractères (même codage)... ce qui a été jugé inacceptable par beaucoup de linguistes chinois et japonais : les sens sont souvent différents, la prononciation aussi, etc.
[^] # Re: Interessant ...
Posté par Trois Singes . En réponse à la dépêche La Poule ou l'oeuf : le livre-application. Évalué à 7.
Bof... en faisant ça, tu enlèves du pouvoir (je n'ose écrire « de la liberté » copyright FSF) à l'utilisateur. Le choix de la Poule lui permet de régler la largeur de sa page comme il le désire. S'il veut voir le texte sur toute la largeur de son 24 pouces, il peut (ça permet notamment de faire ressortir l'organisation d'un chapitre en paragraphes) ; s'il préfère avoir une largeur semblable à un livre (comme tu le préconises), il réduit la taille de sa fenêtre.
Et rien n'a été imposé, tout a été proposé (copyright Siroz pour les connaisseurs).
Au fait : LaTeX fait de grandes marges certes pour la lisibilité mais aussi parce qu'il s'appuie sur les standards américains de la mise en page. En utilisant KOMA-Script, on peut accéder aux standards européens avec des marges notamment réduites.
[^] # Re: Coût d'une telle solution
Posté par Trois Singes . En réponse à la dépêche Nuxeo RCP 2.0 : plateforme client riche pour applications documentaires et multimédias. Évalué à 2.
[^] # Re: Reformulons la question...
Posté par Trois Singes . En réponse à la dépêche Le succès de "MSN" chez les jeunes pose-t-il un problème au logiciel libre ?. Évalué à 2.
Légende urbaine
Petit indice : les points de suspension peuvent être utilisés pour indiquer un sous-entendu dans la phrase précédente, ou comme marque d'ironie. Mais que faisais-tu pendant les cours de français ? ;-)
[^] # Re: Reformulons la question...
Posté par Trois Singes . En réponse à la dépêche Le succès de "MSN" chez les jeunes pose-t-il un problème au logiciel libre ?. Évalué à 2.
Euh... est-ce que ça te viendrait à l'idée de reprocher à la langue anglaise les anglicismes qu'on trouve dans les dissertations des français ?
[^] # Re: Reformulons la question...
Posté par Trois Singes . En réponse à la dépêche Le succès de "MSN" chez les jeunes pose-t-il un problème au logiciel libre ?. Évalué à 1.
Je n'oppose pas les deux raisons, elles sont sans doute justes l'une et l'autre. Je crois que le langage SMS continue d'évoluer, notamment pour encore accélérer la vitesse de frappe (le dictionnaire automatique est une autre manière d'accélérer la frappe, mais c'est un autre usage, concurrent, avec peu de valeur ajoutée pour les utilisateurs habitués au langage SMS).
Ensuite, y a le langage « SMS » porté sur IRC, MSN et consorts. Là encore, ils plaident la rapidité d'écriture.
Je suis d'accord, l'argument ne tient plus hors des messages envoyés par un téléphone portable. Ils feraient mieux d'acheter un Dvorak...
C'est leur argument qui est incorrect dans ce cas (« je fais du SMS dans MSN pour taper plus vite.») Mais ça ne veut pas dire que c'est MAL de faire du SMS via ces médias : c'est un mode de communication différent... Je n'arrive pas à avoir un jugement moral sur cette manière de faire.
[^] # Re: Reformulons la question...
Posté par Trois Singes . En réponse à la dépêche Le succès de "MSN" chez les jeunes pose-t-il un problème au logiciel libre ?. Évalué à 4.
Je ne vois pas trop le rapport de cause à effet. Il y a les SMS et le langage SMS, et il y a le français. Le langage SMS, ce n'est pas du français, c'est un nouveau dialecte, voilà tout. Il existe pour pas mal de bonnes raisons (taper plus vite sur un clavier à 9 touches de 10 cm de côté) ! Alors OK, si tu lis un SMS en mettant en route ton analyseur grammatical de français, ça va le faire hurler. Mais est-ce que c'est grave docteur ? Je dirais non, vu que le langage SMS est lu par ceux... qui l'écrivent couramment ! Ils communiquent, c'est kikoo-lol et tout le monde est content.
Que les professeurs de français ne soient pas satisfaits parce que le niveau en français baisse, je le comprends. Mais qu'ils incriminent les nouvelles technologies, franchement, je ne vois pas le rapport. En tout cas il n'est absolument pas prouvé. On peut lire La redocumentarisation du monde de Roger T. Pédauque, pour voir que plusieurs pédagogues commencent à réfléchir (depuis 10 ans) à l'impact des nouvelles technologies sur la lecture. Par exemple : peut-on lire sur écran ? Ou alors : est-ce que l'acte de lecture change maintenant que les acteurs numériques sont à la fois lecteurs et écrivains ? C'est assez passionnant, mais le champ d'étude en est encore à ses balbutiements.
Dernière petite remarque sur l'orthographe : à quoi ça sert ? Principalement à être sûr que l'autre comprendra bien le message, de manière non-équivoque -- d'ailleurs lorsque je reçois une lettre écrite en français complètement pourri orthographiquement, il m'arrive parfois de douter du sens de certaines phrases ! Et là, c'est la communication qui est coupée !
C'est exactement le même but qui est poursuivi par la typographie (majuscules accentuées, ponctuation, etc.) Malheureusement les défenseurs de ces normes oublient ce côté pratique pour ne voir que le combat contre les infidèles^Wmauvais en orthographe. Ce n'est pas comme ça qu'ils vont les convaincre.
[^] # Re: Commentaire d'un "jeune ado" adepte du Logiciel Libre
Posté par Trois Singes . En réponse à la dépêche Le succès de "MSN" chez les jeunes pose-t-il un problème au logiciel libre ?. Évalué à 4.
LOL
Bon, il y a quand même des indices de ma vieillesse... par exemple lorsqu'il me regarde avec des yeux écarquillés en hurlant : « Non, attends, tu as joué à Myst 1 à sa sortie ??? Et à Alone in the Dark 1 ??? Sans émulateur ??? »...
[^] # Re: Commentaire d'un "jeune ado" adepte du Logiciel Libre
Posté par Trois Singes . En réponse à la dépêche Le succès de "MSN" chez les jeunes pose-t-il un problème au logiciel libre ?. Évalué à 8.
Résultat :
- Trois Singes : Hé, viens voir notre serveur Jabber, c'est super pour travailler en synchro avec le wiki, le téléphone, gna gna gna taxonomies populaires, gna gna gna web 2.0, gna gna gna révolution des usages.
- Beau gosse de 20 ans : bof bof, Jabber j'aime pas, moi mon truc c'est l'IRC.
Là, je comprends plus rien O_o
[^] # Re: Coût d'une telle solution
Posté par Trois Singes . En réponse à la dépêche Nuxeo RCP 2.0 : plateforme client riche pour applications documentaires et multimédias. Évalué à 1.
Je comprends mieux l'opposition que vous faites entre client riche (RPC) et client nouveau-riche (Ajax) ; opposition qui concerne clairement les usages actuels de ces deux méthodes. Le fait que vous vous placiez « dans le cadre de gens qui ont besoin de gérer beaucoup d'information en même temps (y compris sur plusieurs écrans) » est pour moi beaucoup plus clair que lorsque vous écrivez « fournir des fonctions ou une interface utilisateur plus riches que ce qu’on peut réaliser avec les technologies de clients légers ».
Le développement d'interfaces utilisateurs en client riche Java (qu'on utilise les techno Eclipse RCP, autrement dit SWT/JFaces ou les technos Sun comme Swing) reposent sur des concepts qui sont maintenant connus et maîtrisés depuis des années, alors que les interfaces riches en client Web (autrement dit Ajax) sont encore toutes récentes (2-3 ans), avec un foisonnement de bibliothèques et un outillage (support des IDE) encore moyen.
Je ne peux que confirmer ce point. Nos développements Ajax sont effectivement encore plus proche de l'artisanat que de l'industrialisation -- ils sont grisant mais coûteux. Ajax est une rustine qui se colle sur les technologies^Wstandards du web, c'est à la fois bien et mal : bien parce que ces standards sont d'une haute qualité sémantique (attention, je n'ai forcément pas dit technique...) et parce que, à terme, ils permettent un déploiement d'application bien moins cher que des interfaces riches comme Nuxeo : pensez donc, l'architecture web est déjà en place depuis 15 ans ! Mal parce qu'une rustine, ça se décolle, c'est pas facile à fabriquer, il y a 50 méthodes différentes, pas pérennes...
Donc, avec Ajax, développement difficile mais déploiement pas cher... et j'ai l'impression qu'avec les technologies Java, une fois passé le cap de l'apprentissage, c'est l'inverse.
C'est alors l'utilisateur qui départagera, selon l'expérience qu'il veut vivre (et ça rejoint totalement le début de mon commentaire, waow, je devrais écrire plus souvent à 1H20 un dimanche matin). Ça va être passionnant.
Au fait : est-ce que vous avez jeter un œil sur XUL, qui pourrait être un compromis intéressant ? Je crois d'ailleurs que le back-office du journal Le Monde est codé en XUL, ce qui fait un parallèle intéressant avec l'AFP.
[^] # Re: Coût d'une telle solution
Posté par Trois Singes . En réponse à la dépêche Nuxeo RCP 2.0 : plateforme client riche pour applications documentaires et multimédias. Évalué à 2.
C'est justement ce dernier point que j'aimerais voir éclairci. Qu'est-ce qu'un « gain de productivité » ? Pourquoi un coût « pas forcément moins élevé » ? Ce n'est pas du tout une critique de Nuxeo (qui a l'air prometteur) mais plutôt une critique du discours : quels sont les arguments qui démontrent clairement des coûts équivalents et un gain de productivité ?
Effectivement, la gamme actuelle de logiciels Nuxeo ne s'adresse pas aux boutiques (DSI ou intégrateurs) exclusivement PHP ou .NET.
Oui, mais ces boutiques-là devraient pouvoir sortir de leur logique pour voir ce qui se fait à côté. Or Java, c'est très intimidant pour eux. C'est pourquoi je m'étonne que vous ne vous adressiez pas plus à cette communauté, un peu comme Apple qui fait pas mal de bruit autour des switchers ;-)
[^] # Re: 5 minutes
Posté par Trois Singes . En réponse au journal [Sondage] Sans électricité fournie par EDF, votre site tient combien de temps ?. Évalué à 4.
Puis une semaine pour tout rallumer, changer les alimentations qui ont cramé, décoincer le NAS qui est parti avant LDAP, etc. :P
# Autres solutions ?
Posté par Trois Singes . En réponse au message chroot ssh et scp. Évalué à 1.
La solution me semble un peu compliquée. Quelle distribution utilises-tu ? Pour Debian, je me souviens d'une méthode assez efficace utilisant libpam-chroot :
http://www.debian.org/doc/manuals/securing-debian-howto/ap-c(...)
Doit sans doute être applicable à d'autres distributions.
Une autre possibilité est de monter deux serveurs SSH, l'un qui écoute sur un port non standard (pour les admin) et qui tourne hors chroot, et un qui est chrooté, qui écoute sur le port 22 standard, et qui est fait spécialement pour tes utilisateurs.
Si j'ai un peu répondu à côté, en te proposant d'autres méthodes, j'en suis désolé ;-)
# Production des vidéos
Posté par Trois Singes . En réponse au journal Cours du collège de France en ligne. Évalué à 1.
En ce qui concerne la production des vidéos, savez-vous comment ils les ont réalisées ? Notamment pour intercaler vidéo et support ? Est-ce qu'ils passent par une suite logicielle qui « simplifie » le montage, en affichant le transparent dès qu'il change (comme le fait je crois l'association Aristote), où est-ce qu'il y a du montage fait par un bipède ?
Nous essayons de faire ce genre de choses pour automatiser - autant que faire se peut - la vidéo d'une soutenance de thèse ; pour l'instant nous expérimentons SMIL (qui est finalement assez facile à créer automatiquement à partir de plusieurs flux vidéos/images). L'un des inconvénients, c'est que les lecteurs SMIL ne courent pas les rues (Realplayer est presque en situation de monopole ici)...
Pour la diffusion de nos vidéos, la guerre des Flash n'a pas encore eu lieu : nous avons un serveur de streaming (Helix Server et Real Producer, eh non, rien de libre) ; mais nous pensons aussi proposer un lecteur via un lecteur flash, tout simplement parce que le web, de notre point de vue, sert aussi à faire des pages qui incluent esthétiquement texte, image, vidéos, interfaces interactives, etc. comme http://interstices.info/jcms/c_34530/le-tatouage-de-son .
[^] # Re: Business Loto
Posté par Trois Singes . En réponse à la dépêche La forge logicielle LibreSource passe sous GPL. Évalué à 1.
Rassure-toi, ce discours des « communiqués de presse » n'est pas vraiment pris en compte par les établissements publics. Dans le cas d'un marché public, ils n'ont même pas le droit de les lire ;-) Mais le problème est juste déplacé : les sociétés qui répondent aux appels d'offres sont des spécialistes... de la communication appliquée aux appels d'offres ! Et c'est souvent la meilleur com' qui gagne... encore.
Les petits projets libres, pas ceux tirés par des locomotives de la communication comme Greenp^WMoFo, auraient malheureusement bien besoin d'être marketés puis marketing-communiqués... je ne crois pas à la réussite par les seules qualités intrinsèques de l'outil.
Pour citer Chomsky (bouh, une vile analogie rhétorique) : tout le monde sait bien que les républicains sont de moins bons dirigeants que les démocrates, mais leur machine de com' (je crois qu'il a dit « appareil à diffamer ») est bien trop efficace pour qu'ils perdent la présidentielle.
Pour en revenir au texte d'Earered : belle analyse :-)
# Coût d'une telle solution
Posté par Trois Singes . En réponse à la dépêche Nuxeo RCP 2.0 : plateforme client riche pour applications documentaires et multimédias. Évalué à 2.
En ce qui concerne Nuxeo, et le nuage d'applications qui gravitent autour, je me pose la question du coût de mise en place d'une telle solution. La pile logicielle sur laquelle elle repose peut en effet effrayer les équipes informatiques nourries au LAMP :
- Nuxeo RPC
- Nuxeo EP
- JBoss
- Eclipse (+Ant et Maven)
- Java
- J'en oublie peut-être...
Si le parc logiciel est plutôt basé sur des clients légers (applications web), la migration risque de donner des sueurs froides au DSI, coûter cher en formations, en maintenance, ...
(Je me demande d'ailleurs si Nuxeo n'avait pas déjà pris conscience du problème avant de décider d'abandonner Zope/Python pour JBoss/Java, réduisant déjà l'effet "sueurs froides")
Est-ce que certains d'entre vous ont réussi à mettre en place une telle solution dans leur entreprise de manière pérenne et évolutive ? Est-ce que les solutions concurrentes étaient effectivement plus chères/moins performantes ?
[^] # Re: chiffres...
Posté par Trois Singes . En réponse au journal Explosion d'UNICODE sur le web. Évalué à 2.
- Une raison bêtement technique, qui concerne l'UTF-8 plutôt que l'UNICODE d'ailleurs : coder un texte chinois en UTF-8 prend plus d'octets qu'en BIG-5 ou GB (puisque les caractères codés sur peu d'octets en UTF-8 sont plutôt les caractères occidentaux)
- Une raison "sociologique", beaucoup plus grave du point de vue des asiatiques : le consortium Unicode a en effet considéré que les idéogrammes chinois et japonais graphiquement identiques étaient les mêmes caractères (même codage)... ce qui a été jugé inacceptable par beaucoup de linguistes chinois et japonais : les sens sont souvent différents, la prononciation aussi, etc.