ookaze a écrit 271 commentaires

J'ai mis radio-réveil, mais en fait j'ai un Zeo, qui analyse mes cycles de sommeil et me réveille lors d'un changement de cycle, donc toujours en douceur, et je ne me réveille jamais la tête dans le gaz même si je n'ai dormi que 3 heures.

Ce débat est complètement inutile et uniquement par des gens qui résistent au changement sans jamais lire ce qu'on leur explique ou chercher à se documenter.
Parce qu'en fait, on peut tout à fait avoir à la fois journal et un autre système de log sur son système.
Mon rsyslog fournit toujours les logs comme avant (fournies via journal), et journal fonctionne en parallèle. Journal fournit simplement plus d'infos que mon rsyslog, et la seule raison pour laquelle je ne l'ai pas encore jeté (rsyslog) c'est uniquement parce que journal ne gère pas le protocole réseau syslog.
Donc où est le problème ?

Bon, je ne voulais pas que ça passe comme ça, mais au moins j'ai bien fait de poser la question ici, où j'avais plus de chances de te trouver que sur la ML. Mon intuition a été bonne.

Puis, une clarification s'impose!
D'une part, je ne dénigrais pas ta traduction, dont les dernières versions que tu as fourni il y a plus de 6 mois si ma mémoire est bonne, viennent seulement d'être intégrées il y a quelques semaines.
Cette mise à jour était vraiment bienvenue, et a grandement amélioré les choses.

Ensuite, mon intention n'était certainement pas de dire que le travail des traducteurs précédents était mauvais ou incompréhensible (sinon je n'aurai pas cherché à les contacter). Je sais parfaitement qu'il est très difficile de fournir qqch de correct avec les contraintes imposées, et le fait qu'il faille souvent tout vérifier de visu pour être sûr du contexte, et vérifier avec d'autres personnes pour la compréhension.

L'état actuel de la traduction est due à de nombreux facteurs, comme un grand nombre de textes ajoutés ou modifies, les nombreux sujets qu'il faut connaître, les nouvelles API qui permettent plus de liberté (ou moins), les modifications d'interface, des fonctionnalités, ... à ajouter à la difficulté d'une traduction et d'une éventuelle adaptation du texte.

Ce qui m'embête le plus dans la "localisation" actuelle de MythTV, ce sont en fait tous les passages non traduits, donc ce n'est pas du tout le travail des traducteurs qui m'embête le plus. J'ai déjà fait plusieurs traductions bénévolement, je sais le travail que cela représente, et loin de moi l'idée de dénigrer leur travail.
Chez moi c'est surtout flagrant parce que j'utilise MythWelcome, et on est accueilli par de magnifiques gros messages en anglais :)).
C'est simple, si tout avait été traduit, je n'aurai même pas réagi.

Donc voilà, je suis désolé d'avoir vexé, ce n'était pas l'intention.

M'enfin, je sais maintenant que je peux continuer le boulot.
Merci.

Non non non!
Je sais parfaitement comment traduire, je connais cette page, j'utilise cette méthode.
Mon problème est que je ne veux pas faire un travail redondant ou en contradiction avec des règles établies.
Mon problème ne concerne pas la traduction, mais de trouver le traducteur officiel français, s'il y en a un.

Bon, de toute évidence il n'y en a pas, et je compte sur les utilisateurs français pour discuter des normes de traduction, une fois que j'aurai fourni les patches. Mine de rien, les fichiers à traduire sont énormes (surtout celui de mythfrontend), donc je comprend mieux pourquoi cela n'a pas encore été mis à jour.

A noter que j'ai déjà posé cette question sur la ML de développement

Lecture quand tu nous tient ...

S'il y a un traducteur français officiel pour MythTV, et s'il lit DLFP, pourrait-il me contacter ?
La version française actuelle de MythTV est horriblement incompréhensible dans le peu d'endroit où elle est traduite.
Ceci contribue à maintenir le sentiment que MythTV est compliqué à configurer (il n'est juste pas ergonomique du tout).

Je travaille actuellement sur la traduction de toute l'interface, et de la doc, et donc, il serait bon d'en discuter. A noter que j'ai déjà posé cette question sur la ML de développement.
L'espoir est d'avoir, pour la 0.22, une interface graphique totalement traduite en français, consistante et compréhensible, que ce soit pour MythTV ou ses greffons officiels.

Merci

Rebooter après voir désinstallé la glibc serait une grave erreur : vous pouvez être sûr de ne pas récupérer le système.
Mieux vaut réinstaller une nouvelle glibc avant de rebooter quoi que ce soit.

Ce n'est peut-être pas vrai pour cette version, mais en 2.6.17, smartctl supportait sans problème un disque SATA au travers de libata.
Il y a juste une option à ajouter pour qu'il aille chercher les infos par libata.

Je dois avoir des lignes de ce genre dans mon /etc/udev/rules/10-local.rules :
KERNEL=="eth*", SYSFS{address}=="MAC_sensible_casse", NAME="nom_interface_max_8_lettres"

Je ne saisplus quel paquet oblige à limiter le nom de l'interface réseau à 8 caractères max.
Je lance udev très tôt dans la séquence de boot, donc pas de souci.
Sinon, si qqch monte une interface avant qu'udev modifie le nom, tu ne peux plus le changer et tu restes avec eth*, si ton driver est dans le noyau.

Que veux-tu dire ?
Je change l'attribution de nom de mes interfaces avec Udev, et il décide en fonction de la MAC address (sensible à la casse depuis peu) chez moi.
Je ne vois pas où est le problème, tu peux même scripter la détermination des MAC address si tu veux, avant de les passer à udev.

C'est que à chaque fois que je mets à jour mon DBus, je relance le daemon système pour qu'il prenne la nouvelle version en cours, et par la suite, toutes mes applis utilisant DBus refusent de se lancer et préfèrent planter. Les dbus utilisateurs continuent de tourner, mais ils sont en fait inutilisables (et ça l'a toujours fait, même avec des versions mineures de DBus).
Et j'ai fait les tests une fois avec les outils en ligne de commande fournis, et effectivement, je n'arrivais plus à obtenir quoi que ce soit.
Ca m'est arrivé aussi bien sous Gnome que sous KDE.
K3B s'en sortait bien, il restait juste bloqué pendant plusieurs minutes.
Rhythmbox en revanche ...
Ceci dit, K3B recherchait des infos HAL, alors que Rhythmbox voulait communiquer avec libnotify (enfin, je pense).

Une relance de chaque session (qui relance aussi les daemons DBus utilisateurs), règle le souci.

Un point important à mon sens avec D-BUS est que normalement, cela ne tourne pas en root. Chacun a le sien. Je ne sais pas par contre comment les D-BUS communiquent entre eux ? (Le D-BUS utilisateur est-il client du D-BUS système)

Les dbus utilisaeurs ne tournent pas en root, mais le dbus système tourne en root au moins au lancement, pour lacher ses droits ensuite.
Le dbus système, je ne sais pas s'il est serveur, mais il communique avec tous les autres, comme un fédérateur. S'il tombe, tous les autres tombent avec (enfin, deviennent inutilisables).

Cela est un plus par exemple avec le service 'fam' de notification de mofication de fichier qui devait absolument tourner en root, avec les problèmes que l'on connait pour les périphériques amovibles

fam est toujours nécessaire. Gamin est plus adapté à la plupart des gens, et n'a pas besoin de tourner en service.

Un autre point important est que D-BUS est un bus de messages et de signaux. Cela n'a donc rien à voir avec un système de variable globale de type base de registre ou gconf

Etant donné que GConf utilise également des messages et des signaux (surtout), je me pose des questions quant au "ça n'a rien à voir".

Comme le dit la réponse de la FSF, la clause sur les brevets était déjà présente en GPLv2, mais sure d'être appliquée uniquement aux USA, ce n'était pas clair pour le reste du monde. En GPLv3, c'est bien expliqué pour éviter ce travers.
Donc ton brevet deviendrait la même chose qu'en GPLv2 : le même qu'avant l'utilisation de la GPL pour ton code.
Tu ne pourrais toujours pas faire un procès à ceux qui utilisent ton brevet au travers du code GPL que tu distribues, ce qui ne change rien à ton brevet et au fait que tu peux faire un procès à ceux qui l'utilisent dans autre chose que ton code GPL.

Non, ce n'est pas la même chose.
Je fais référence à ce problème : https://wiki.ubuntu.com/Core_2_Duo_Support

Désolé, c'est en anglais.

Vu le gros bug présent sur un driver PATA utilisé sur la plupart des meilleures cartes mères pour Core 2 Dual, qui touche pas mal de distros avec live CD (parce que malheureusement, la plupart des gens ont un lecteur optique sur PATA, et du coup, il n'est pas reconnu), le passage au 2.6.18 serait extrêmement sage, car ce driver buggé est présent dans le 2.6.17. Quoiqu'ils peuvent choisir de patcher aussi.

j'ai fais un peu de sniff sur les pages recuperées lors d'un grab, il y a un beau javascript dedans faisant une redirection de page et c'est tout... ils ont un peu plus blindé leur site contre xmltv :-(

Ils ont surtout viré une fonctionnalité : voir les programmes de la semaine sur une plage horaire pour plusieurs chaînes simultanément.
Malheureusement, c'est la page qu'utilisait tv_grab_fr, car c'était plus efficace et taxait moins le site.
Le hack que j'ai fait taxe bien plus le site, il se borne, du coup, à récupérer jour par jour et chaîne par chaîne.
Ca m'a pris 1 heure pour faire le hack, mais mes programmes étaient bons jusqu'à vendredi, donc pas de souci de mon côté.
Cependant, on devrait avoir une roue de secours dans le grabbeur, parce que le jour où le hack prend plus d'1 heure à faire, on risque d'être mal (enfin, moi, avec ma femme, qui n'a pas manqué de me dire lundi, que ses séries du samedi et dimanche prochains n'étaient pas programmées).
Quelqu'un a-t-il déjà implémenté le nxtepg avec MythTV ?

Dites, la probabilité de 2 sources pour xmltv tombent en même temps est réellement minime, ne serait il pas utile de maintenir 2 parsers? Disons télépoches et http://www.cesoirtv.com/fr/programme.htm ?

C'est ce qu'on se disait sur la ML. J'ai pas regardé celui-là, mais j'ai été voir Télérama, Télé Z, et un autre : pas praticable !
J'irai voir ce site.

On a beau être rompu à la ligne de commande et adooooorer potasser de longues docs, une application qu'on peux lancer directement après son installation, c'est pas mal.

Quand je te lis, une image flagrante me vient à l'esprit. Tu es exactement dans le même état d'esprit que la plupart des gens dans leur magasin, qui demandent au vendeur si leur télé aura déjà les chaînes réglées. C'est le même souci avec MythTV : à moins qu'on te loue un technicien, à moins qu'il y ait un profil tout près pour ta configuration (hertzien, çâble, ADSL, TNT, un mélange de tout ça), tu devras lire cette longue doc livrée avec le matériel, et configurer toi-même.
Le pire, c'est que MythTV est encore plus puissant, mais donc encore plus complexe, qu'une TV ou un magnétoscope.
Tout ça pour dire que l'appli dont tu parles est installée avec MythTV.
Et à vrai dire, le plus dur à configurer en général, ce n'est pas MythTV, c'est tout ce qu'il y a autour.

Frontend + backend + mysql deriere quand y a un truc qui déconne c'est la croix et la bannière pour résoudre un soucis.

Quand y a un truc qui déconne sur mes Linux, c'est toujours matériel ou externe à l'OS, A MOINS que j'ai été tout pêter avec mes gros doigts, mais dans ce cas, c'est moi le responsable. C'est précisément pour cela que MythTV était si attirant pour moi : j'ai entièrement confiance en la stabilité de l'ensemble.
Résultat : 0 problèmes dus à MythTV en 8 mois d'utilisation.

Là j'ai un probleme, les enregistrements que je programme ne sont plus mémorisés.
Impossible de savoir d'où vient le probleme.

Tu veux dire qu'ils ne sont plus programmés. Déjà en utilisant les bons mots, ça va mieux.
Ce qui doit être dû au fait que depuis vendredi dernier, Télépoche a modifié son site, donc tv_grab_fr ne fonctionne plus.
Le mainteneur a dit qu'il fallait prendre son mal en patience pour que Télépoche répare leur site.
Personnellement, j'ai hacké tv_grab_fr afin de créer une version qui fonctionne, j'attends l'avis du mainteneur pour diffuser le résultat à ceux qui ne peuvent pas attendre (comme moi) que Télépoche répare, s'ils en ont l'intention.

De plus mythtv utilise une configuration par hostname dans mysql.
En fait tous les settings sont stockés par hostname dans la base, du coup c'est quasi impossible de migrer une config proprement, et encore moins de changer de nom d'hôte.

En fait c'est tout à fait possible, mais faut connaître le SQL. Ou c'est peut-être déjà sur le Wiki de MythTV.

Pour ce qui est stocké en base utiliser SQL est completement inutile.

Je ne suis pas d'accord.

a la limite pour pour les librairies de mp3 en encore

Et les programmes TV alors ? Tous ceux que tu as déjà enregistrés surtout.

aussi l'interface est completement non ergonomique, et allez savoir pourquoi, les developpeurs s'entêtent à ne pas vouloir supporter la souris, parceque eux ils ont des télécommandes

Ma femme semble apprécier grandement cette interface non ergonomique, et elle l'a très vite maîtrisée, pourtant elle fait des trucs bien compliquées avec, sans s'en rendre compte. En fait, elle maîtrise mieux que moi, elle l'utilise aussi beaucoup plus que moi. Et elle n'y connaît rien à l'informatique.
De plus, les souris sont supportées, au mois depuis cette version, puisque les "mouse gestures" sont supportées maintenant.

mythtv c'est vraiment le soft cliché Linux par exellence.
Imbaisable :D

J'aurai dit : fonctionne et fait vraiment tout ce qu'ils disent qu'il fait, terriblement efficace, et surtout, plus puissant que tout le reste.
Pas pour être pédant, c'est juste que tout ce qu'il fait en plus, est utile, voire indispensable parfois.

Est-ce qu'on peut essayer de lister les utilisations qui sont faites de SQL dans MythTV? Est-ce qu'on peut mettre ca en regard du nombre de fonctionnalites offertes par MySQL?

MythTV utilise la majorité des fonctionnalités de MySQL. Sans aller très loin, mais suffisamment pour que la 0.19 soit impactée par un bug sur un JOIN spécial de MySQL. De plus, MythTV peut fonctionner en synchro avec plusieurs backends (comprendre plusieurs MySQL entre autres), donc toute l'utilité d'une BDD se fait vite sentir dans un tel cas, sans compter les nombreuses données qui entrent régulièrement dans la base en provenance de diverses sources, en simultané. Il y a un script d'optimisation de la base dans les sources, que l'on peut lancer en cron.

Si on utilise moins de 5% des capacites de MySQL on peut decemment sortir l'analogie de la centrale nucleaire et la lampe de poche

On est plutôt à 70 % qu'à 5 %.

Un stockage ad-hoc base sur des fichiers et des recherches via dictionnaires offrerait peut-etre les memes fonctionnalites?

Non.

Ou sinon un moteur SQL minimaliste qui ne requiert pas de maintenance?

L'installation ne requiert pas de maintenance. Tu peux lancer le script d'optimisation si tu en as envie. Rien de plus.

MySQL ne se maintient pas tout seul: comme tout moteur de DB il y a foultitude de parametres a regler.

N'importe quoi ! Tu as à autoriser ton user mythtv, fermer l'accès externe, en gros c'est tout. C'est expliqué dans la doc.
Et mon install est compilé et custom de A à Z, donc mon MySQL est d'origine, j'ai rien eu de plus à configurer, et ça tourne tout seul depuis des mois.
Ah si, tu peux mettre en cron la sauvegarde régulière d'un dump de ta base sur une autre machine.

On peut sans doute se contenter des parametres par defaut mais l'install generique qui est faite e.g. dans Ubuntu n'a pas conscience qu'elle va etre utilisee pour MythTV.

Tu devrais plus te renseigner sur ce qu'est une BDD et sur le fonctionnement de MySQL, ou simplement lire la doc de MythTV.

Qu'est-ce qui me garantit qu'une install par defaut est valide pour MythTV sur toutes les distribs?

Le fait que chez moi ça marche, avec l'install de base faite par un "make install" et une copie du default-my.cnf (ou un truc comme ça) ?

On peut aussi imaginer que j'utilise le daemon mysqld en local a d'autres fins et que mes reglages customises soient conflictuels avec MythTV.

Relis mon avis plus haut sur le fonctionnement d'une BDD et de MySQL.

Par contre c'est imposer a ses utilisateurs (et donc a soi-meme) une charge supplementaire d'installation et de maintenance (fut-elle minimale) d'un soft non negligeable.

Ohlala ! Encore une fois : zéro maintenance, et MySQL se compile tout seul. Avec une distro, rien à faire.

Etant donné que la TV en direct de MythTV est du "Live TV", signifiant que MythTV enregistre d'abord, puis que tu vois ce qui a été enregistré avec un décalage de 2 secondes, cela implique que tu dois forcément pouvoir regarder les chaînes de la Freebox en direct.

Mais bon, le WEP, comme tu le dis, a un remplaçant qui tient la route depuis 3 ans et est connu pour être définitivement trop faible depuis 2001

Je ne suis pas d'accord sur le fait que le WEP soit inutile, je dis que cela dépend du contexte.
Bien sûr dans l'absolu, le WPA c'est mieux, mais :
- ça demande plus de ressources, pas toujours disponibles
- c'est plus compliqué pour connecter des appareils "grand public"
Ca doit être pour ça que ça émeut pas grand monde, à part les entreprises et les informaticiens.
L'utilisateur lambda il s'en fiche que tu squattes sa ligne ADSL, de toutes façons il paye pas au débit ou à l'heure.
L'utilisateur lambda est plus préoccupé par ce truc compliqué qu'il faut rentrer dans sa DS pour jouer à Mario Kart DS, ce truc qu'il sait même pas où aller chercher.
J'ose pas imaginer en WPA. Et le développeur de la DS, qui n'arrive pas à caser du WPA dans les ressources de sa DS, est bien obligé de faire du WEP.

Ce n'est qu'une technique, très ingénieuse et efficace, et un outil de plus parmi pleins d'autres pour lui faire la peau. Mais bon, si c'est celle qui fait bouger les gens, alors tant mieux. Parce que même la pléthore de démos et vidéos de crack de WEP en moins de 15 minutes ne semblaient pas émouvoir grand monde...

Ben moi j'ai de sérieux doutes quand même. Pour reprendre l'exemple plus haut, je pense qu'il y a déjà largement plus de gens qui jouent à Mario Kart DS en ligne que de gens qui ont vu ces vidéos ... AMHA, le WEP en a encore pour un petit moment au niveau du grand public.
Pour les autres (professionnels, entreprises, ...) je dis pas.
Pour chez moi, le facteur risque/performance n'est pas en faveur du WPA du tout ...

en fait il s'avere que ce que ce qui est fait ici est le patch tres localisé (à chaque occurence de l'instruction concernée) pour la remplacer par celle adéquate sur cette famille de pross. "et si elle est plus longue" ai-je tout de suite pensé? si elle est plus courte on rajoute des NOPs. donc ça doit s'aligner sur la plus longue possible. super.

Alignement sur la plus longue possible qui ne pose pas de problèmes même sur du 32 bits, ça doit même pouvoir être mieux.

on va me dire c'est quoi deux NOPs? c'est ça de perdu dans le pipeline et je vois pas trop de justification...

C'est pourtant simple (en théorie) : si l'instruction résultante est plus rapide que celle de départ, qui elle est plus générique.

ce serait plus simple d'avoir deja compilé un kernel par archi et de tout switcher au boot...c'est si gros que ça un kernel?(j'y connais pas grand ch.. heu que dalle). ou alors c'est pas assez modulaire pour ça?

Ben euh, c'est pas le problème des développeurs du kernel ça, mais celui des distros. Tu n'es pas obligé d'activer l'option non plus hein !

bien sur dans ces cas là on peut pas switcher pendant que ça tourne mais je me demande pourquoi on peut avoir besoin de switcher pendant que ça tourne...

CPU hotplug, gestion des pertes de CPU, distributions avec kernel générique.

de plus d'aut gens emettent l'hypothese que ça pourrait creer des deadlocks (rapport au SMP là)

Ca a été fait justement pour le SMP. Des bugs sont toujours possibles évidemment.

Les protocoles associés, c'est RTP, qui établit une connexion UDP entre deux ports négociés via SIP, et c'est un beau bazar pour gérer ça correctement

Au niveau de netfilter, ils ont intégré le conntrack et le NAT pour RTP/RTSP et plusieurs protocoles P2P (module ipp2p).
Le SIP n'est géré que par patch (dans patch-o-matic-ng) pour le moment.
Je trouve que c'est une plus grande nouvelle que H323. Le RTSP va me permettre d'enfin accéder aux chaînes de Free à travers mon firewall, et je vais pouvoir à nouveau bloquer les connexions vers l'extérieur sur mon firewall. J'avais tout autorisé, car ça me ralentissait ou bloquait le P2P (cause ports aléatoires bloqués par le firewall).
Il faut peut-être patcher iptables avec patch-o-matic-ng pour gérer ces protocoles.

c'est un confort extrême d'avoir un PC qui boot rapidement

J'ai du mal à comprendre en quoi gagner 3 secondes (allez, disons 10) sur 90 (ou même sur 60) est un confort extrême.

Un PC allumé, çà reste bruyant, çà chauffe, et çà consomme

Admettons que ce n'est pas la solution.

Je me log, je lis mes mails... zut ! çà sent le crâmé.. je cours éteindre sous ma mixture, et je peste contre GNU / linux !

Je peste contre GNU/Linux alors que si mon repas a crâmé, c'est parce que je lisais mes mails ... Evident ! Logique !
C'est pas les 3 secondes (allez, disons 10) de plus au boot qui ont fait crâmé le repas, à moins d'être d'une insondabe mauvaise foi.

Ajoutons que nous autres qui passons le plus clair de notre temps libre devant un écran ne sommes peut-être pas les plus concernés par le problème, mais la personne qui considère son ordinateur comme un appereil électroménager est sévèrement agacée par ce système conçu pour des serveurs qu'on éteint jamais

C'est du n'importe quoi. Ma femme en est très contente justement, que ce soit le linux familial pour lire ses mails, qui lui reste allumé en permanence (et se trouve dans la chambre en plus), que le "media center" du salon qui donne la main à la télécommande en moins d'une minute( faudra que je chronomètre tiens), et dont elle se sert comme un appareil électroménager (enfin, comme d'un magnétoscope super évolué, cause MythTV dessus).
C'est sûr 3 secondes de plus c'est mieux, mais déjà que je la vois pas jubiler quand il est déjà allumé (càd 0 seconde de boot) parce qu'il enregistre une émission, alors je vois pas où est le confort extrême pour quelques secondes de moins.