la seul contrainte que j'ai c'est qu'il faut que firefox ce ferme à la fin du diapo, ou qu'on puisse savoir quand le diapo/vidéo à terminé afin de continuer la playliste...
En fait si tu exportes ta diapo en vidéo flv et que tu utilises le player opensource (si ça n'a pas changé) JW player ( http://www.longtailvideo.com/players/jw-flv-player/ ), tu pourras contrôler la vidéo via du javascript très simple et savoir quand la vidéo se termine pour balancer un autre contenu (toujours via javascript)
En clair avec un peu de php (ou autre) + javascript + JW player + css + firefox tu peux faire un truc relativement light (si j'ai de bons souvenirs ça tournait sur une VM avec 64mb de ram, fluxbox configuré pour lancer FF au démarrage, ff en plein écran sans barre d'outils ni de tâches et prototype + scriptaculous pour les effets)
Firefox dispose d'un plugin pour l'ouvrir direct en plein écran (va voir sur geckozone ou ton moteur de recherche favori, j'ai un trou sur son nom là tout de suite)
Après, je sais que c'est pas le top mais compte tenu des contraintes, il y a webkit qui pourraît être plus léger, et il y a aussi des plugins d'intégration d'OOo à firefox qui pourraient te permettre de tout lancer dans FF
Tu peux aussi utiliser preload qui accélèrera le lancement des applis
Enfin, crade mais intégrable facilement (déjà réalisé) tu peux exporter tes présentations en swf, films aussi, sons aussi, et faire tout afficher dans FF : tout ne se lance qu'une seule fois.
Si t'as besoin d'aide, j'ai déjà réalisé une base avec la dernière solution, je pourrais essayer de te retrouver des éléments si ça t'intéresse.
Non plus... c'était d'actualité (et encore.) lorsque les navigateurs ne grossissaient QUE le texte (et pas le reste) ce qui ne sert pas à grand chose du point de vue de l'accessibilité : les gens qui ont besoin de grossir le texte d'une page web, ont besoin de grossir le texte de TOUTE l'interface, et utilisent pour cela la "loupe" intégrée à leur environnement. La capacité à grossir le texte est une béquille quasi inutilisable en l'état, même avec un site "prévu pour" (suffit de tester pour s'en apercevoir : le texte perd toute sa structure visuelle et il devient pénible et déroutant de le lire).
On peut produire des sites se conformant à WCAG-AAA (et testé par des humains) sans pour autant permettre un grossissement infini du texte, simplement parce qu'il est bien plus pratique (et utilisé) d'utiliser une "loupe" logicielle ou d'utiliser la fonctionnalité de zoom des navigateurs récents.
Je pousserais même la chose plus loin : si tu veux vraiment faire de l'accessibilité, il conviendra de proposer une css paramétrable permettant d'augmenter le contraste en permettant de choisir une couleur différente pour le texte et le fond en plus de permettre le choix d'un type de police (chasse fixe, avec ou sans serif, neutralisation des italiques etc...) du document, en plus de la css par défaut.
Je pense que tu n'as pas compris du tout : il veut pas se faire ch*** pour faire une capture d'écran correcte pour l'impression, donc il utilise le zoom de FF qui ne fait pas qu'agrandir la taille du texte... (il fait un VRAI zoom sur la page, comme on le ferait sur un document PDF via evince par exemple) et non, si ça rend mal c'est que le thème ne s'y prête pas (boîtes trop peu larges pour accueillir de gros caractères), ce qui est le cas de la très grande majorité des thèmes graphiques qui sont un tant soit peu esthétiques...
C'est là que je me pose la question de la pertinence de la création d'un utilitaire de gravure spécifique à KDE... pourquoi ne pas créer UN utilitaire de gravure avec un front-end différent selon qu'on veuille l'utiliser sous x ou y, afin de ne pas avoir à importer les 3/4 d'un autre environnement (avec ses services etc...) pour l'utiliser ?
Pouvez-vous deviner que VLC, Arora, psi ou scribus, ne sont pas des application GTK+ lorsque elle sont lancée sous Gnome?
our beaucoup de devs qui découvrent le Libre, «Linux = GNOME, programmer pour Linux = programmer pour GNOME», et ça fait qu'on arrive avec des trucs comme PackageKit qui est inutilisable sous KDE parce que totalement orienté GNOME.
L'inverse est hélas également très vrai : certains devs découvrant le libre ont l'impression qu'il n'y a que Qt et que lier intimement une application générique (ie: qui pourrait très bien être utilisé dans un autre environnement, comme un utilitaire pour graver des CD) est d'une logique toute naturelle... et il y en a beaucoup plus, hélas...
Lorsque tu crées un contenu non indexable, il convient d'en fournir un équivalent indexable (attribut title pour la balise img voire, le cas échéant le alt) sous flash tu ne peux apporter ce genre de précision.
Le fait qu'ils travaillent à l'accessibilité ne date pas d'hier, Macromedia a déjà tenté son lot d'améliorations... on sais où ça a mené
Concernant le CPU c'est *aussi* un problème sous win.
Vu la quantité de bonne volonté qu'il y a dans la communauté, à la place d'Adobe, je libèrerais au moins une grande majorité du code (pour ne pas dire tout) afin que cette même communauté, d'une, cesse de cracher sur flash, et de deux l'améliore dans le bon sens (les idées et les cerveaux ne manquent pas)
Non c'est Artisteer : c'est un soft qui permet de chier un thème graphique en quelques clics. il utilise un formatage html de base (valide soit dit en passant) et y ajoute une feuille de style + images. voir : http://www.artisteer.com
Le contenu non valide est dans les textes et autres éléments rajoutés aux templates.
justement : lorsqu'on demande une adresse pourquoi ne pas mettre "adresse" ? lorsqu'on veut ton adresse postale, on ne met pas "postale" tout court non ?
Tous les dev web ne font pas de flash... la grande majorité des choses pour lesquelles flash est utilisé couramment peuvent être faites autrement (css pur ou css+javascript+dom) et depuis longtemps...
Si dans un formulaire, tu trouves adresse, tu met quoi ? 15 rue des alouettes ou totor@trifouilly.gallinacée.net ?
Et pourquoi pas ce qui existe déjà ? soit "adresse de courrier électronique ? ok c'est long mais c'est la traduction directe de "email address" et ça ne porte pas à confusion (et c'est Mme. Muchu aware) voire simplement... adresse email ?
En quoi safe_mode=on est-il plus une fausse sécurité que expose_php=off ou display_errors=off ?
Parce que le safe mode est tout sauf safe et introduit même de l'insécurité... en plus du fait que certains se permettent n'imp sous prétexte qu'ils sont en safe-mode...
Le expose_php et display_errors à off permettent simplement de ne pas donner trop d'infos concernant la configuration du serveur, ça évite, par exemple, que des robots scanent les page d'un serveur à la recherche d'une version de php ou d'une appli web particulière connue pour avoir telle et tell faille. Ça n'est pas, en soi un rempart infranchissable, mais ça permet d'éviter d'être trop facilement repéré.
> [1] on peut aussi utiliser son propre gestionnaire d'erreur (en le codant)
> qui ne les affichera que pour tel ou tel visiteur, selon l'ip ou le domaine,
Excellente idée pour introduire encore plus de failles potentielles.
Le but de la manœuvre étant de ne pas afficher les erreurs pour le quidam ou simplement l'utilisateur final mais permettre aux mainteneurs d'avoir un retour en cas d'erreur, voire un meilleur retour : inscription dans une bdd des données utiles (utilisateur identifié, page, variables de session et tout ce qui peut être utile au debug) voire alerte plus importante dans le cas ou telle ou telle erreur survient sur tel ou tel script.
Évidemment, c'est comme tout, quand on sait pas faire : vaut mieux ne pas faire... si on garde ça en tête, on devrait éviter certaines grosses failles...
Si on va dans ce sens, la meilleur façon de ne pas avoir d'emmerde : c'est ne pas héberger de site web...
facile... oui si la machine (hôte du chroot) est déjà compromise (à l'aide d'un fifo par exemple) ou si le chroot est mis en place avec les pieds et sans réfléchir... d'un autre coté, si on ne sait pas qu'il y a un chroot, on ne va ptet pas forcément chercher à en sortir...
Par contre, en cours développement, il FAUT afficher TOUS les avertissements (et le corriger bien sûr ;-)).
Oui mais normalement on restreint l'accès aux scripts en dev... ou alors on n'affiche les erreurs que pour le dev
C'est encore activé par défaut ces horreurs ?
ça dépend des distributions, et puis on ne sait jamais, si on arrive après un admin foireux, on pourra les trouver activées...
Ce modèle de sécurité (liste noire) est bancal à mon avis.
peut être mais on a pas le choix, et d'un autre coté ça permet d'être plus souple dans la gestion de la liste : en supprimant les fonctions à risque, on est relativement tranquille par la suite... et vu le nombre de fonctions de PHP, la lite noire sera toujours plus rapide à constituer et lire que la blanche.
Moui. Enfin, il faut aussi remonter les alertes au webmestre. Il existe par exemple http://php-ids.org/
je m'interroge sur l'utilité de remonter ça au mainteneur : si un utilisateur légitime a oublié son mot de passe : il le redemandera, les autres seront de faux utilisateurs essayant de trouver le mot de passe d'un utilisateur légitime... qu'est-ce qu'il s'en tape le mainteneur de savoir qu'un type a essayé de craquer un pass ? tant que le bloquage est efficace...
Je pense qu'il vaudrait mieux créer un utilisateur MySQL aux droits restreints (ex : LOAD_FILE / SELECT INTO / ... sont-ils vraiment utiles sur un site web ?).
ça dépend de ce que tu fais avec ton "site web"... et puis pour l'utilisateur : c'est évident je pense.
De ma petite expérience, PHP souffre de plusieurs problèmes :
on est déjà au courant et c'est hors de propos : l'objet du journal n'est pas de connaître les pb de php ou d'en faire le procès ni de le comparer à d'autres langages et n'est pas non plus un appel aux trolls poilus, mais juste une demande de constitution d'une liste de choses à faire pour sécuriser php autant que faire se peut.
Tout ce que tu dis est évident et notoire, cependant même en sachant ça, on ne sait pas forcément comment se prémunir de ces risques : ce journal devrait permettre à certains de savoir comment faire, point barre.
[^] # Re: Petit joueur....
Posté par jeffcom . En réponse au journal ha le php et ses élites. Évalué à 7.
[^] # Re: Scrinnechote
Posté par jeffcom . En réponse au journal Une css opensuse pour linuxfr. Évalué à 10.
[^] # Re: Bon, plusieurs problèmes
Posté par jeffcom . En réponse au journal Serveurs de fichiers. Évalué à 4.
Heureusement, par contre, on nous colle Win dans les pattes sans nous demander notre avis... mais c'est un autre débat...
(les phrases stupides ca peut aller dans les 2 sens tu sais)
Dans ce cas précis, c'était vraiment une phrase stupide, en effet.
[^] # Re: Quelques idées
Posté par jeffcom . En réponse au journal Une solution pour difux? (Diffusion de contenu sur écran). Évalué à 2.
En fait si tu exportes ta diapo en vidéo flv et que tu utilises le player opensource (si ça n'a pas changé) JW player ( http://www.longtailvideo.com/players/jw-flv-player/ ), tu pourras contrôler la vidéo via du javascript très simple et savoir quand la vidéo se termine pour balancer un autre contenu (toujours via javascript)
En clair avec un peu de php (ou autre) + javascript + JW player + css + firefox tu peux faire un truc relativement light (si j'ai de bons souvenirs ça tournait sur une VM avec 64mb de ram, fluxbox configuré pour lancer FF au démarrage, ff en plein écran sans barre d'outils ni de tâches et prototype + scriptaculous pour les effets)
[^] # Re: Plone est écrit en Python
Posté par jeffcom . En réponse au journal Firefox interdit par l'administration Wallonne. Évalué à 10.
# Quelques idées
Posté par jeffcom . En réponse au journal Une solution pour difux? (Diffusion de contenu sur écran). Évalué à 2.
Après, je sais que c'est pas le top mais compte tenu des contraintes, il y a webkit qui pourraît être plus léger, et il y a aussi des plugins d'intégration d'OOo à firefox qui pourraient te permettre de tout lancer dans FF
Tu peux aussi utiliser preload qui accélèrera le lancement des applis
Enfin, crade mais intégrable facilement (déjà réalisé) tu peux exporter tes présentations en swf, films aussi, sons aussi, et faire tout afficher dans FF : tout ne se lance qu'une seule fois.
Si t'as besoin d'aide, j'ai déjà réalisé une base avec la dernière solution, je pourrais essayer de te retrouver des éléments si ça t'intéresse.
[^] # Re: Plone est écrit en Python
Posté par jeffcom . En réponse au journal Firefox interdit par l'administration Wallonne. Évalué à -4.
[^] # Re: Copies d'écran
Posté par jeffcom . En réponse au journal J'ai auto-édité un livre - Atelier Drupal (Suite). Évalué à 4.
On peut produire des sites se conformant à WCAG-AAA (et testé par des humains) sans pour autant permettre un grossissement infini du texte, simplement parce qu'il est bien plus pratique (et utilisé) d'utiliser une "loupe" logicielle ou d'utiliser la fonctionnalité de zoom des navigateurs récents.
Je pousserais même la chose plus loin : si tu veux vraiment faire de l'accessibilité, il conviendra de proposer une css paramétrable permettant d'augmenter le contraste en permettant de choisir une couleur différente pour le texte et le fond en plus de permettre le choix d'un type de police (chasse fixe, avec ou sans serif, neutralisation des italiques etc...) du document, en plus de la css par défaut.
[^] # Re: Copies d'écran
Posté par jeffcom . En réponse au journal J'ai auto-édité un livre - Atelier Drupal (Suite). Évalué à 3.
[^] # Re: Excellent !
Posté par jeffcom . En réponse au journal Résultats du Google Summer of Code 2009 pour KDE. Évalué à 0.
Pouvez-vous deviner que VLC, Arora, psi ou scribus, ne sont pas des application GTK+ lorsque elle sont lancée sous Gnome?
euh... oui... et inversement... logique...
[^] # Re: Excellent !
Posté par jeffcom . En réponse au journal Résultats du Google Summer of Code 2009 pour KDE. Évalué à 1.
L'inverse est hélas également très vrai : certains devs découvrant le libre ont l'impression qu'il n'y a que Qt et que lier intimement une application générique (ie: qui pourrait très bien être utilisé dans un autre environnement, comme un utilitaire pour graver des CD) est d'une logique toute naturelle... et il y en a beaucoup plus, hélas...
[^] # Re: Utilité ?
Posté par jeffcom . En réponse au journal Gnash: décodage fluide de vidéos Flash HD (H.264). Évalué à 3.
Le fait qu'ils travaillent à l'accessibilité ne date pas d'hier, Macromedia a déjà tenté son lot d'améliorations... on sais où ça a mené
Concernant le CPU c'est *aussi* un problème sous win.
Vu la quantité de bonne volonté qu'il y a dans la communauté, à la place d'Adobe, je libèrerais au moins une grande majorité du code (pour ne pas dire tout) afin que cette même communauté, d'une, cesse de cracher sur flash, et de deux l'améliore dans le bon sens (les idées et les cerveaux ne manquent pas)
[^] # Re: Utilité ?
Posté par jeffcom . En réponse au journal Gnash: décodage fluide de vidéos Flash HD (H.264). Évalué à 6.
[^] # Re: Y'a du mieux.
Posté par jeffcom . En réponse au journal Bouteille à la mer. Évalué à 4.
Le contenu non valide est dans les textes et autres éléments rajoutés aux templates.
[^] # Re: expressions courantes
Posté par jeffcom . En réponse au journal Expressions clichées. Évalué à 2.
[^] # Re: Utilité ?
Posté par jeffcom . En réponse au journal Gnash: décodage fluide de vidéos Flash HD (H.264). Évalué à 8.
Tous les dev web ne font pas de flash... la grande majorité des choses pour lesquelles flash est utilisé couramment peuvent être faites autrement (css pur ou css+javascript+dom) et depuis longtemps...
[^] # Re: expressions courantes
Posté par jeffcom . En réponse au journal Expressions clichées. Évalué à 3.
Et pourquoi pas ce qui existe déjà ? soit "adresse de courrier électronique ? ok c'est long mais c'est la traduction directe de "email address" et ça ne porte pas à confusion (et c'est Mme. Muchu aware) voire simplement... adresse email ?
[^] # Re: D'autres trucs
Posté par jeffcom . En réponse au journal Sécurisation d'applications PHP hébergées sur du LAMP. Évalué à 2.
Parce que le safe mode est tout sauf safe et introduit même de l'insécurité... en plus du fait que certains se permettent n'imp sous prétexte qu'ils sont en safe-mode...
Le expose_php et display_errors à off permettent simplement de ne pas donner trop d'infos concernant la configuration du serveur, ça évite, par exemple, que des robots scanent les page d'un serveur à la recherche d'une version de php ou d'une appli web particulière connue pour avoir telle et tell faille. Ça n'est pas, en soi un rempart infranchissable, mais ça permet d'éviter d'être trop facilement repéré.
> [1] on peut aussi utiliser son propre gestionnaire d'erreur (en le codant)
> qui ne les affichera que pour tel ou tel visiteur, selon l'ip ou le domaine,
Excellente idée pour introduire encore plus de failles potentielles.
Le but de la manœuvre étant de ne pas afficher les erreurs pour le quidam ou simplement l'utilisateur final mais permettre aux mainteneurs d'avoir un retour en cas d'erreur, voire un meilleur retour : inscription dans une bdd des données utiles (utilisateur identifié, page, variables de session et tout ce qui peut être utile au debug) voire alerte plus importante dans le cas ou telle ou telle erreur survient sur tel ou tel script.
Évidemment, c'est comme tout, quand on sait pas faire : vaut mieux ne pas faire... si on garde ça en tête, on devrait éviter certaines grosses failles...
Si on va dans ce sens, la meilleur façon de ne pas avoir d'emmerde : c'est ne pas héberger de site web...
[^] # Re: Accès FTP
Posté par jeffcom . En réponse au journal Sécurisation d'applications PHP hébergées sur du LAMP. Évalué à 2.
[^] # Re: bug sur linuxfr ..?
Posté par jeffcom . En réponse à la dépêche Publication de la liste des startups retenues pour les "Open Innovation Awards". Évalué à 2.
[^] # Re: Des principes, en vrac, que j'utilise
Posté par jeffcom . En réponse au journal Sécurisation d'applications PHP hébergées sur du LAMP. Évalué à 2.
Pas plus d'infos concernant «chroot vs jail BSD»
[^] # Re: Accès FTP
Posté par jeffcom . En réponse au journal Sécurisation d'applications PHP hébergées sur du LAMP. Évalué à 3.
[^] # Re: Nero, pas GNU
Posté par jeffcom . En réponse au journal Sortie de Nero Linux 4. Évalué à -1.
tout s'explique...
[^] # Re: Nero, pas GNU
Posté par jeffcom . En réponse au journal Sortie de Nero Linux 4. Évalué à 4.
tu vas publier les sources ?
[^] # Re: D'autres trucs
Posté par jeffcom . En réponse au journal Sécurisation d'applications PHP hébergées sur du LAMP. Évalué à 3.
Par contre, en cours développement, il FAUT afficher TOUS les avertissements (et le corriger bien sûr ;-)).
Oui mais normalement on restreint l'accès aux scripts en dev... ou alors on n'affiche les erreurs que pour le dev
C'est encore activé par défaut ces horreurs ?
ça dépend des distributions, et puis on ne sait jamais, si on arrive après un admin foireux, on pourra les trouver activées...
Ce modèle de sécurité (liste noire) est bancal à mon avis.
peut être mais on a pas le choix, et d'un autre coté ça permet d'être plus souple dans la gestion de la liste : en supprimant les fonctions à risque, on est relativement tranquille par la suite... et vu le nombre de fonctions de PHP, la lite noire sera toujours plus rapide à constituer et lire que la blanche.
Moui. Enfin, il faut aussi remonter les alertes au webmestre. Il existe par exemple http://php-ids.org/
je m'interroge sur l'utilité de remonter ça au mainteneur : si un utilisateur légitime a oublié son mot de passe : il le redemandera, les autres seront de faux utilisateurs essayant de trouver le mot de passe d'un utilisateur légitime... qu'est-ce qu'il s'en tape le mainteneur de savoir qu'un type a essayé de craquer un pass ? tant que le bloquage est efficace...
Je pense qu'il vaudrait mieux créer un utilisateur MySQL aux droits restreints (ex : LOAD_FILE / SELECT INTO / ... sont-ils vraiment utiles sur un site web ?).
ça dépend de ce que tu fais avec ton "site web"... et puis pour l'utilisateur : c'est évident je pense.
De ma petite expérience, PHP souffre de plusieurs problèmes :
on est déjà au courant et c'est hors de propos : l'objet du journal n'est pas de connaître les pb de php ou d'en faire le procès ni de le comparer à d'autres langages et n'est pas non plus un appel aux trolls poilus, mais juste une demande de constitution d'une liste de choses à faire pour sécuriser php autant que faire se peut.
Tout ce que tu dis est évident et notoire, cependant même en sachant ça, on ne sait pas forcément comment se prémunir de ces risques : ce journal devrait permettre à certains de savoir comment faire, point barre.