Bravo pour la bidouille. Je n'aurai pas été capable d'en faire autant.
Je me suis déjà amusé avec les fonctions réseau de pulseaudio.
En résumé il y a 4 façon de diffuser du son sur un réseau avec pulseaudio :
Tunnel pulseaudio (protocole natif pulseaudio)
RTP idéal pour diffuser vers un client compatible rtp comme VLC
AirPort RAOP / AirTunes qui malheureusement ne semble pas compatible avec la version 2 du protocole. (ne fonctionne pas avec la Freebox par exemple)
DLNA/UPnP fonctionne en association avec rygel (tutoriel). Fonctionne avec la Freebox malgré quelques défauts.
J'ai tout testé et tout fonctionne sauf AirTunes. Toutes ces méthodes sont assez simples à mettre en place avec l'interface graphique paprefs. Il est aussi possible d'utiliser pacmd à condition de bien connaître pulseaudio.
Pendant ma formation j'ai eu l'occasion d'écrire quelques documents. J'ai pas mal bidouillé LaTeX, j'ai fait un peu de OOo, DokuWiki et j'ai même essayé DocBook.
Pour moi trois critères sont importants pour la production de document :
Qualité du document produit
Pour ça LaTeX est le meilleur même si DocBook se défend (voir les bouquins O'Reilly). Quoi qu'il en soit, le travail sur les modèles de documents est toujours prépondérant et devrait être fait par des connaisseurs. Trouver des modèles de qualité adaptés à un besoin n'est pas une mince affaire.
Séparation du fond et de la forme
D'abord pour que le rédacteur se concentre pleinement sur sa tâche et ensuite pour permettre de produire plusieurs sorties à partir d'une même source. Sur ce point DocBook me semble le plus aboutit comme le montre la quantité de balises définies par défaut comme "email", "editor", "revision" etc.
Lisibilité de la source
C'est là que le bât blesse. Le rédacteur passe quand même la majeure partie de son temps sur la source du document à écrire ET à relire ce qu'il écrit. Personnellement, même avec une belle coloration syntaxique, j'ai du mal à relire du LaTeX ou du DocBook. Sur ce point, les WYSIWYG sont quand même plus confortables.
Et alors ?
Pour m'approcher de mon idéal, j'ai testé dblatex pour marier DocBook et LaTeX et le plugin LaTex pour DokuWiki pour avoir une source lisible, avec séparation du fond et de la forme et un beau document LaTeX. Cette dernière solution n'offre cependant pas la souplesse nécessaire pour subvenir à tous les besoins.
P.S. J'ai oublié la facilité de rédaction mais c'est un détail. Un peu d'autocomplétion et le remapping de "\" (ou pour DocBook la fermeture automatique des balises) et le tour est joué.
C'est pas si compliqué finalement le principe des MAC. La mise en œuvre après je ne sais pas...
J'aime bien l'idée de faire de la sécurité avec quelque chose qui est fait pour ça, et je pense que c'est plus intéressant à apprendre.
J'ai déjà vu tourner tripwire lors d'un stage mais je n'avais pas pensé à l'utiliser. Le souvenir que j'ai c'est qu'il y a beaucoup (trop) d'alertes inutiles (notamment à cause des màj). Je pense qu'il doit falloir apprendre à l'utiliser.
Puppet et CfEngine sont fait a priori pour surveiller les services et les relancer si besoin mais je ne sais pas comment ils se maintiennent eux mêmes en service.
Merci pour toutes ces précisions et pour la mise au point finale.
Effectivement, mes besoins sont d'assurer :
1 - la confidentialité de certaines données
2 - l'intégrité des données du serveur
3 - la continuité des services (à mon niveau bien sûr, pas à 100%)
Pour 1 j'ai pensé chiffrer les partitions de sauvegarde rsync.
Pour 3 j'ai pensé à un gestionnaire de configuration type puppet et une application de monitoring type Nagios (il faudrait que je trouve plus adapté à ma situation).
Pour 1, 2 et 3 la virtualisation ou l'isolation peuvent être aussi utiles en cloisonnant les données et les services (d'où ma question).
Je ne connais pas très bien les MAC, DAC, apparmor et compagnie, mais c'est peut être ce qu'il me faut.
Quelle différence en terme de sécurité par rapport à l'isolation / la virtualisation ?
Je n'ai encore jamais essayé BSD alors je ne vais peut-être pas faire mes premiers pas d'auto-hébergement avec, mais BSD est en haut de ma liste de trucs à découvrir.
LXC, ça a l'air très bien aussi. Simple et surtout parfaitement intégré à Linux.
J'ai trouvé un cas d'utilisation assez proche du mien => http://artisan.karma-lab.net/node/1749
Quelqu'un d'autre a testé ?
Si quelqu'un de ILV ou de Bookeen passe par là, ce serait bien qu'il nous éclaire...
Ce serait génial si on pouvait installer un OS libre spécialisé comme OpenInkPot -> http://openinkpot.org
Le bookeen Opus est noté comme - Stalled (somebody worked on it, but no longer does) - dans la page des eReader supportés par OpenInkPot.
Hormis leur prix légèrement prohibitif et le contraste encore assez faible, je suis vraiment convaincu par cette technologie. Je passe plusieurs heures par jour à lire sur écran et la fatigue engendrée par le rétroéclairage finit par être sensible. De plus, avoir un petit appareil pour s'installer tranquillement ou on veut peut être confortable.
Il faut également remarquer que cette technologie consomme très peu d'énergie par rapport à la lecture sur LCD ou même LED.
En bon libriste, je m'inquiétait de pouvoir accéder / modifier l'OS de mon eReader. Est-ce vraiment possible avec l'ILV Opus ?
A quand les ordinateurs portables avec des écran ePaper ?
(un peu comme l'OLPC avec le mode transmissif et réflexif)
Mais pourquoi faudrait-il être un utilisateur avancé pour pouvoir apprécier robustesse, simplicité et efficacité ?
Un programme simple et ergonomique est-il une utopie ?
À mon avis il est aussi compliqué de savoir fermer une fenêtre avec Alt-F4 qu'avec Fichier > Quitter. La seul différence est que la seconde méthode peut se découvrir au petit bonheur la chance...
Mais pourquoi donc Fichier > Quitter pour fermer une application ?
Très bon résultat (pour mes humbles oreilles). Bien meilleur que le Prologic de mon décodeur. Ça faisait longtemps que je voulais arriver à profiter de mon 5.1 pour la musique (avec autre chose que du stéréo x2).
La mise en place n'a pas été immédiate pour moi (Ubuntu Jaunty x86_64 - ampli 5.1 en S/PDIF). D'autant que je ne suis pas un crack.
J'ai aussi dû mettre un filtre de suréchantillonnage parce que la lecture de certaines vidéos avec mplayer était très lente.
cf. [http://www.johannes-bauer.com/dolby/] tout en bas.
[^] # Re: Sandstorm
Posté par Gmax . En réponse au message Sandstorm, installer des appli serveur comme des appli mobiles. Votre avis ?. Évalué à 1.
Toutes les infos sont dans la doc (assez bien fournie) : https://docs.sandstorm.io/
# Pulseaudio, c'est simple !
Posté par Gmax . En réponse au journal Transférer du son en réseau avec Pulseaudio, VLC, et un clavier bépo. Évalué à 3. Dernière modification le 03 juin 2012 à 12:00.
Bravo pour la bidouille. Je n'aurai pas été capable d'en faire autant.
Je me suis déjà amusé avec les fonctions réseau de pulseaudio.
En résumé il y a 4 façon de diffuser du son sur un réseau avec pulseaudio :
J'ai tout testé et tout fonctionne sauf AirTunes. Toutes ces méthodes sont assez simples à mettre en place avec l'interface graphique
paprefs. Il est aussi possible d'utiliserpacmdà condition de bien connaître pulseaudio.Doc sur pulseaudio.org : http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Network
# Le graal
Posté par Gmax . En réponse au sondage Mon système de composition de documents préféré est :. Évalué à 4.
Pendant ma formation j'ai eu l'occasion d'écrire quelques documents. J'ai pas mal bidouillé LaTeX, j'ai fait un peu de OOo, DokuWiki et j'ai même essayé DocBook.
Pour moi trois critères sont importants pour la production de document :
Qualité du document produit
Pour ça LaTeX est le meilleur même si DocBook se défend (voir les bouquins O'Reilly). Quoi qu'il en soit, le travail sur les modèles de documents est toujours prépondérant et devrait être fait par des connaisseurs. Trouver des modèles de qualité adaptés à un besoin n'est pas une mince affaire.
Séparation du fond et de la forme
D'abord pour que le rédacteur se concentre pleinement sur sa tâche et ensuite pour permettre de produire plusieurs sorties à partir d'une même source. Sur ce point DocBook me semble le plus aboutit comme le montre la quantité de balises définies par défaut comme "email", "editor", "revision" etc.
Lisibilité de la source
C'est là que le bât blesse. Le rédacteur passe quand même la majeure partie de son temps sur la source du document à écrire ET à relire ce qu'il écrit. Personnellement, même avec une belle coloration syntaxique, j'ai du mal à relire du LaTeX ou du DocBook. Sur ce point, les WYSIWYG sont quand même plus confortables.
Et alors ?
Pour m'approcher de mon idéal, j'ai testé dblatex pour marier DocBook et LaTeX et le plugin LaTex pour DokuWiki pour avoir une source lisible, avec séparation du fond et de la forme et un beau document LaTeX. Cette dernière solution n'offre cependant pas la souplesse nécessaire pour subvenir à tous les besoins.
P.S. J'ai oublié la facilité de rédaction mais c'est un détail. Un peu d'autocomplétion et le remapping de "\" (ou pour DocBook la fermeture automatique des balises) et le tour est joué.
[^] # Re: Virtualisation... Mais c'est quoi
Posté par Gmax . En réponse au message Quand utiliser la virtualisation. Évalué à 2.
J'aime bien l'idée de faire de la sécurité avec quelque chose qui est fait pour ça, et je pense que c'est plus intéressant à apprendre.
J'ai déjà vu tourner tripwire lors d'un stage mais je n'avais pas pensé à l'utiliser. Le souvenir que j'ai c'est qu'il y a beaucoup (trop) d'alertes inutiles (notamment à cause des màj). Je pense qu'il doit falloir apprendre à l'utiliser.
Puppet et CfEngine sont fait a priori pour surveiller les services et les relancer si besoin mais je ne sais pas comment ils se maintiennent eux mêmes en service.
[^] # Re: Virtualisation... Mais c'est quoi
Posté par Gmax . En réponse au message Quand utiliser la virtualisation. Évalué à 1.
Effectivement, mes besoins sont d'assurer :
1 - la confidentialité de certaines données
2 - l'intégrité des données du serveur
3 - la continuité des services (à mon niveau bien sûr, pas à 100%)
Pour 1 j'ai pensé chiffrer les partitions de sauvegarde rsync.
Pour 3 j'ai pensé à un gestionnaire de configuration type puppet et une application de monitoring type Nagios (il faudrait que je trouve plus adapté à ma situation).
Pour 1, 2 et 3 la virtualisation ou l'isolation peuvent être aussi utiles en cloisonnant les données et les services (d'où ma question).
Je ne connais pas très bien les MAC, DAC, apparmor et compagnie, mais c'est peut être ce qu'il me faut.
Quelle différence en terme de sécurité par rapport à l'isolation / la virtualisation ?
[^] # Re: Jails ?
Posté par Gmax . En réponse au message Quand utiliser la virtualisation. Évalué à 1.
Je n'ai encore jamais essayé BSD alors je ne vais peut-être pas faire mes premiers pas d'auto-hébergement avec, mais BSD est en haut de ma liste de trucs à découvrir.
LXC, ça a l'air très bien aussi. Simple et surtout parfaitement intégré à Linux.
J'ai trouvé un cas d'utilisation assez proche du mien => http://artisan.karma-lab.net/node/1749
Quelqu'un d'autre a testé ?
[^] # Re: Bonne initiative
Posté par Gmax . En réponse à la dépêche Une liseuse libre pour lire des livres libres. Évalué à 1.
Il est clair que la rapidité et le nombre de couleur sera limité mais 16 couleurs ça suffit pour un terminal ;-)
L'idéal serait la possibilité comme sur l'OLPC de passer de l'un à l'autre...
[^] # Re: Bonne initiative
Posté par Gmax . En réponse à la dépêche Une liseuse libre pour lire des livres libres. Évalué à 2.
Ce serait génial si on pouvait installer un OS libre spécialisé comme OpenInkPot -> http://openinkpot.org
Le bookeen Opus est noté comme - Stalled (somebody worked on it, but no longer does) - dans la page des eReader supportés par OpenInkPot.
# Bonne initiative
Posté par Gmax . En réponse à la dépêche Une liseuse libre pour lire des livres libres. Évalué à 6.
Il faut également remarquer que cette technologie consomme très peu d'énergie par rapport à la lecture sur LCD ou même LED.
En bon libriste, je m'inquiétait de pouvoir accéder / modifier l'OS de mon eReader. Est-ce vraiment possible avec l'ILV Opus ?
A quand les ordinateurs portables avec des écran ePaper ?
(un peu comme l'OLPC avec le mode transmissif et réflexif)
-------
un wiki sur les eReader : http://wiki.mobileread.com/
# Un peu d'air frais...
Posté par Gmax . En réponse à la dépêche Présentation du projet suckless. Évalué à 6.
Mais pourquoi faudrait-il être un utilisateur avancé pour pouvoir apprécier robustesse, simplicité et efficacité ?
Un programme simple et ergonomique est-il une utopie ?
À mon avis il est aussi compliqué de savoir fermer une fenêtre avec Alt-F4 qu'avec Fichier > Quitter. La seul différence est que la seconde méthode peut se découvrir au petit bonheur la chance...
Mais pourquoi donc Fichier > Quitter pour fermer une application ?
# Merci de nous faire partager ce travail
Posté par Gmax . En réponse au journal FreeSurround Alsa Plugin. Évalué à 2.
La mise en place n'a pas été immédiate pour moi (Ubuntu Jaunty x86_64 - ampli 5.1 en S/PDIF). D'autant que je ne suis pas un crack.
Il faut d'abord passer par la compilation des plugins alsa :
cf. [http://forum.ubuntu-fr.org/viewtopic.php?id=246509]
Et la compilation de mplayer : (Erreur: pcm_a52.c : Cannot find codec engine)
cf. [http://ubuntuforums.org/showthread.php?t=1165897]
J'ai aussi dû mettre un filtre de suréchantillonnage parce que la lecture de certaines vidéos avec mplayer était très lente.
cf. [http://www.johannes-bauer.com/dolby/] tout en bas.
Encore merci.