Puyb Inside

mardi 28 février 2006

FireFox 3

Bon, une petite image marrante pour clore le chapitre sur les navigateurs ;-) !!!

Commença FireFox n'est pas facile d'accès ;-)
Splasho - The Superbrowser

dimanche 26 février 2006

Freebox Multiposte Suite

Sur la requête de Mala116, je viens de mettre en ligne les binaires d'OpenWRT avec le patch RTSP pour pouvoir router comme il faut le protocole RTSP. Ces binaires s'installent comme une distribution OpenWRT classique. Ils fonctionnent sur les Linksys WRT54g, les Asus WL500g et bien d'autres modèles.
OpenWRT est une distribution qui nécessite une très bonne connaissance de Linux (notamment d'iptables). Les fichiers sont livrés tel quel et sans garantie autre que l'assurance que ça marche sur mon matériel (un Asus WL500g). Si vous n'avez pas les connaissances requises, ne vous lancer pas dans l'aventure. Sinon, je vous recommande de lire la documentation OpenWRT avant d'aller plus loin...


Bonne chance ;-)

Toujours sur Internet Explorer

Pierre a osé dire, dans un commentaire :
j'ai essayé FireFox, et je suis revenu en courant à AvantBrowser (base IE) sans hésiter un instant. Je n'arrive toujours pas à comprendre ce que tout le monde trouve à ForeFox... pour moi c'est buggué, et plusieurs sites ne passent pas bien. Alors c'est facile de dire du mal de IE, mais je n'ai pas moins de problèmes avec FireFox.
Personnellement, mon browser de prédilection est Safari d'Apple...

Je ne préconise pas FireFox plus qu'un autre... (enfin, si, peut être un peu quand même)... Mais je préconise de ne pas utiliser les navigateurs basé sur IE...

Le moteur de rendu d'IE ne respecte pas les standards de l'internet... Si Internet existe, c'est grâce aux standards !
Les sites qui ne passent pas sur FireFox eux aussi ne respectent pas ces standards (pour pouvoir fonctionner sur Internet Explorer.
Personnellement, je ne les remarque même pas, même si je surf dessus... ça fait plus de 4 ans que je n'utilise plus Internet Explorer (remplacé par Mozilla, puis FireFox, puis Safari). Ces sites devraient respecter les standards ! Ne pas respecter les standards veut dire qu'il ne respectent pas leur visiteurs selon moi (vu que c'est au visiteur de faire l'effort d'avoir du matériel compatible avec le site...) !!!

Sinon, FireFox ne souffre d'aucun problème de stabilité chez moi, et ce quelque soit la plateforme (Windows, Linux ou MacOSX, j'utilise régulièrement les 3)... Je pense qu'a mon avis, les bugs dont tu parle sont surtout imputable aux site !!!
Pour info, il existe plusieurs tests de conformité :
Pour les navigateurs, il y a par exemple le test Acid2 qui permet de tester la conformité avec CSS2. Le but du jeu est d'afficher une page un peu compliqué... Normalement, on doit obtenir ça avec un navigateur entièrement compatible avec la norme CSS2. Pour l'instant, à ma connaissance, seul Safari réussi complètement ce test... Firefox donne un résultat satisfaisant, mais IE se plante misérablement (oui, je sais ce n’est pas flagrant)...
Valid XHTML 1.0 Strict Sinon, on peut tester si une page respecte les standards avec des outils comme le W3C Validator ou le CSS Validator. Vous verrez qu'il est effarant de voir le nombre de sites qui ne respectent pas les standards... Et ce surtout pour les sites qui ne s'affichent correctement que sur IE...

J'espère en tout cas qu'IE 7 va enfin mettre fin a cette tradition qu'a Microsoft de toujours vouloir dévier des standards...
C'est comme ça qu'on arrive à avoir 2 web... les compatibles Microsoft et les normaux... avec entre deux, un bon nombre de pauvre webmestres tiraillé entre les deux camps et qui essaye tant de bien que mal de réconcilier tout le monde... Personnellement, j'ai choisi mon camp !!!

samedi 25 février 2006

Bande de voleurs !!!

Selon un post sur /., le futur format vidéo HD DVD ne s'affichera pas en pleine résolution sur la plupart des téléviseurs HD vendu actuellement...
En effet, ils ont décidés que les téléviseurs HD non équipés de prise HDMI avec une puce de DRM HDCP ne recevront qu'un signal dégradé en 960 x 540 pixels au lieu de 1920 x 1080 pixels !!! C'est une arnaque... Tous les gens qui ont acheté des téléviseurs HD actuellement se sont fait arnaquer...

Le pire, c'est qu'ils osent affirmer que c'est pour lutter contre le piratage...
Ont-ils compris que ce genre de protections, comme celles qu'il y avait sur le DVD, n'empêchent pas les vrais pirates de faire leurs affaires, mais gênent surtout les consommateurs honnêtes !!!
Où alors, ils ont trop bien compris qu'ils ne pourront pas lutter contre les pirates, alors ils cherchent à faire payer leurs soit disantes pertes aux gens qui payent déjà...

Le pire dans leur logique, c'est qu'il autorise des produit comme le DVIHDCP ou le DVIMAGIC. Ces produits permettent de récupérer le signal numérique débarrassé de la protection anti-copie HDCP. Même pas besoin pour un pirate de casser le code du HDCP, il lui suffit de posséder un boîtier comme celui la et une carte d'acquisition DVI pour pouvoir inonder le net de copies pirates...
Je ne comprend même pas comment SPATZ a pu obtenir une licence pour utiliser les puces HDCP dans ses produits...

Internet explorer...

Get Firefox! Dans un commentaire, Rnò a osé dire :
Au fait, ta colonne de droite, quand tu veux tu la fais revenir à droite (au lieu d'être reléguée tout en bas)... gniarkgniark...

Ne comprenant pas bien de quoi il voulait parler, car cette colonne est très joliment (à mon goût) fixé sur la droite sur tous mes navigateurs, je suis aller étudier d'un peu plus prêt la configuration de notre ami :
ip-du-rno - - [24/Feb/2006:21:03:11 +0100] "GET / HTTP/1.1" 200 51509 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon; SV1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50215)"

Aie, que vois-je, Rnò, qui est pourtant quelqu'un de très bien malgré le fait qu'il soit sous Windows, utilise encore un navigateur de l'âge pré-internet !!!

Pour ceux qui débarquent, Internet Explorer, est un navigateur alternatif, qui ne supporte absolument pas les standard de l'internet a savoir, actuellement, le CSS 2.
J'en ai marre de me prendre la tête a chercher des astuces bâtardes pour essayer d'avoir un truc a peut près présentable sur ce navigateur... J'ai donc décidé de façon unilatérale de ne plus supporté ce navigateur...

Tampis pour la minorité de personne qui continue, sans doute par accoutumance, à utiliser cette infâmité !!!
Pour les autres, utilisez FireFox ou Safari

vendredi 24 février 2006

Un virus sur Mac

La communauté est en émoi... Heise.de à trouver un "Virus" pour mac...

Il n'y a pas de virus sur Mac et certain s'était fait à l'idée que ce fait était immuable... Franchement, ce n'est parce que MacOSX est a basé d'Unix qu'il est immunisé contre les Virus... Pour preuve, Linux est lui aussi victime d'un vrai virus en ce moment... Par contre, je pense que la non-prolifération des Virus est du a plusieurs facteurs...
Premièrement, MacOSX représente une très faible part de marché... C'est un argument de poids quand on sait que beaucoup de virus ou de troyens servent de nos jours à convertir la machine en relais à Spam. Dans ce cas, le Virus est donc un buisness, et comme les jeux vidéo, les spammeurs préfèrent se concentrer sur l'omniprésent Windows... Mais, cela n'explique pas pourquoi il n'y a pas des programmateurs du dimanche qui essayent de faire des Virus... Je pense <sarcastique> que les utilisateurs de Mac sont des gens beaucoup plus cool que les utilisateurs de PC et qu'ils ne font pas ce qu'ils ne voudraient pas qu'on leur fasse ;-) <sarcastique>...
La part de marché est un phénomène qui peut limiter fortement l'expansion des vers... En effet, les vers cherchent a contaminer d'autre machine en les attaquant... La faible proportion de Mac fait qu'il risque d'avoir bien du mal à trouver des victimes... Le virus pour linux est un peu victime de ce phénomène...
Par contre, je pense que la conception de MacOSX le rend tout de même un peu plus insensible au virus... L'architecture Unix fait par exemple que le Virus a les mêmes droits (limitation) que l'utilisateur qui l'a lancé... Cela veut dire que ne peut modifier que ce que l'utilisateur a le droit de modifier... Par exemple, si un utilisateur lance un Virus, celui-ci ne pourra pas s'installer confortablement au coeur du système... Même si l'utilisateur est administrateur ! En effet, les administrateurs sous MacOSX, sont, contrairement à Windows, de simples utilisateurs qui ont juste le droit de demander à exécuter des taches en tant qu'administrateur, et ce uniquement après une authentification de l'utilisateur (une sorte de sudo graphique)... Bref, si un virus veut obtenir les droits administrateurs, il devra demander à l'utilisateur d'entrer son mot de passe... Gageons que celui-ci trouvera suspect que la photo cochonne qu'il vient de recevoir d’un ami Russe, lui demande son mot de passe administrateur ;-)
D'autre part, MacOSX dispose de petit mécanisme pour éviter qu'un utilisateur ne lance une application sans s'en rendre compte (une application déguisée en image par exemple)... Lors du téléchargement d'une application, un message d'avertissement apparaît explicitement pour prévenir du danger...
Le problème, c'est quand le virus arrive aussi à berner ce mécanisme... Et c'est précisément ce qu'a réussi à faire Heise.de... Ils ont trouvé une faille dans le mécanisme de protection ;-)

Le principe de l'attaque est simple. MacOSX, contrairement à Windows, n'utilise pas (enfin, peu serait plus juste) sur le système des extensions de nom de fichier pour déterminer avec quel programme il doit ouvrir un fichier. Il utilise à la place des méta-données (données extérieures au fichier, comme un commentaire, les dates, ou même le nom du fichier ;-) ) pour stocker le type du fichier... Grâce a ce type, il peut connaître la ou les applications prenant en charge le fichier. De plus, on peut ordonner au système d'utiliser une application précise pour ouvrir un fichier. Dans ce cas, le chemin de l'application est stocké dans une méta-donnée... Cette manipulation est très simple, il suffit d'afficher les infos d'un fichier, puis de choisir un autre programme dans la section Ouvrir avec.

Jusque-là, c'est plus une super fonctionnalité qu'une faille de sécurité...
Mais, car il y a forcément un mais ;-), quand on crée une archive zip, les méta-données sont aussi copier dans l'archive (le dossier MACOSX que l'on voit dans les archive sous Windows). Ce qui veut dire que je peux vous envoyer un fichier, et vous forcer (si vous n'y prêtez pas attention) à l'ouvrir avec le programme de mon choix... Les archives zip ne sont pas la seule façon de transmettre les méta-données, on peut aussi le faire avec un client email supportant l'encodage type mac double (Apple Mail par exemple), ou encore simplement avec un disque formaté en HFS+ ou un partage réseau AFS...
Heise.de exploite cette faille en déguisant un script shell (une sorte de petit programme) en une image jpeg... Pour cela, ils assignent au fichier une extension .jpg et une icône d'image, mais le programme à utiliser pour ouvrir ce fichier, est forcé sur Terminal.app, ce qui a pour effet d'exécuter le script...
Le problème ici, c'est que personne ne vous a prévenu que ce qui ressemblait à une image était en fait un dangereux programme... L'avertissement prévenant que l'on télécharge un programme s'est lui aussi fait berner par l'extension .jpg que portait le fichier...

J'aimerais déjà signaler que ce n'est pas Safari qui est a l'origine de cette faille... L'ouverture du même fichier téléchargé par Firefox, ou obtenu par n'importe quelle autre méthode, se terminera invariablement de la même façon... Le problème de Safari est dû à l'option d'ouverture automatique des fichiers téléchargés, avec cette option, le simple fait de télécharger le fichier fait qu'il sera exécuté... Ce qui fait qu'une page avec un javascript ou un rafraîchissement automatique peut très bien lancer le téléchargement sans aucune intervention... J'ai toujours désactivé cette option qui est malheureusement activée par défaut... Tout le monde devrait en faire de même... à commencer par Apple lui même !!!

Certains préconisent de déplacer Terminal.app... En effet, le chemin de l'application étant marqué en dure dans les méta-données, déplacer Terminal.app est une bonne parade... pour les scripts qui utilisent Terminal.app... Qui nous dit que d'autres programmes ne peuvent pas être utiliser de la même façon ? Préparez vous à déplacer toutes vos applications... D'autre part, je peux vous dire que si vous commencez comme ça, la prochaine mise à jour système risque de se passer plutôt mal ;-)

La solution n'est pas d'essayer de réparer le système qui prévient lors du téléchargement (même si ça ne ferait pas de mal)... Car ce système n'est pas inclus dans tout le système, mais uniquement présent dans Safari... Par contre, comme le dit John Gruber, il faudrait qu'Apple revoie le mécanisme utiliser pour ouvrir un fichier. Les méta-données ne devrait pas être prise en compte si elles sont importées depuis un système étranger (ou si elle ne sont pas directement faite par l'utilisateur...).

Dans tous les cas, il faut arrêter de croire que l'on peut cliquer partout sans conséquence... Un minimum de paranoïa évite déjà pas mal de problème...

Update 3/03/2006 : La mise à jour de sécurité 2006-001 corrige le bug de Safari (et aussi d'iChat). Les scripts shell déguisé sont de nouveau considéré comme des applications. Néanmoins, je conseille tout de même de ne pas cocher la case "ouvrir les fichiers téléchargés automatiquement".

Par ma fenêtre

Voilà le paysage que j'ai vu par ma fenêtre en me levant ce matin... Oui, il neige en Normandie. Ce n'est pas exceptionnel, mais j'adore ça !
Ah, Vivement les vacances au ski !




Au passage, vous pourrez noter la formidable qualité de mon APN... Un Revio C2 (1Mpixel, 16 Mo de mémoire, optique fixe) que ma mère m'a gentiment ramené du Japon il y a 3 ans... Un téléphone portable fait mieux (sauf mon T610), mais il a au moins le mérite d'exister ;-)

Et il y en a qui travaillent ???

Voici une visite en photo du GooglePlex, le campus de Google...

C'est le paradis des Geeks !!!

Mais je me demande s'il y en a qui travaillent là dedans ??? Où alors ceux qui travaillent vraiment sont enfermés à la cave ???

jeudi 23 février 2006

SPAM

Ah, c'est vraiment le fléau de notre monde virtuel...

Comme Choiz ou Rno, ce blog est aussi victime du Spam...
J'ai donc décider de mettre en place un test de turing nommé captcha (oui, ça s'éternue en un seul mot !!!)...
Ce test, contrairement à beaucoup d'autres, fait plus appel à votre intelligence qu'à vos talent de Champollion !!! Il vous suffit de répondre à une question simple, écrite dans un texte lisible... Le principe de ce test tient dans le fait que peu de spameurs s'amuse à faire des robots capables de comprendre notre belle langue ;-)
Franchement, là, si ça ne marche toujours pas, je ne sais pas quoi faire...

mardi 21 février 2006

Vrac

Oui, je sais, je ne suis jamais très inspiré pour faire de long titres...
  • CreamMonkey est pour Safari, l'équivalent de GreaseMonkey (qui lui est pour Firefox)... C'est a dire un système qui permet d'afficher des sites en utilisant des filtres pour les rendre plus beau, plus ergonomique, ou pour disposer de fonctions supplémentaires... Dans le principe, c'est un Javascript qui se charge de défigurer le site...
    C'est intéressant, mais il est dommage de voir que les scripts CreamMonkey et GreaseMonkey sont incompatible. Par contre, pour le nom, je vois pas pourquoi Cream....
  • Wikicalc est un Wiki / Tableur à la sauce Ajax... Impréssionant et par Dan Bricklin, le créateur de VisiCalc (pour les non culturé, le premier tableur ;-) )...
  • J'ai bossé un peu sur le proxy rtsp2http...
    J'ai ajouté le support de connexion multiples (via des threads) et un système de re-connexion automatique si la liaison avec la Freebox est interrompue.
    Le multi-connexion n'est pas du tout testé... Mais au moment ou j'écris ces ligne, je me rend compte qu'il ne marchera pas car tout les threads essaye d'écouter sur le même port UDP... Bref, à revoir...
    Par contre, je me suis aperçu que je devais, pour maintenir la liaison RTSP avec la Freebox plus de 30s, envoyer des paquets de réponses toutes les 5s... Ce paquet donne des infos sur le dernier paquet reçu, etc... Donc, je crois que je vais définitivement être obliger d'interpréter un peu plus le header...
    Comme d'habitude, c'est disponible ici (download)

jeudi 16 février 2006

Transfert de donnée escargot...

Le transfert n'est pas rapide, mais c'est compensé par une MTU de presque 9Go...



Via Make:

dimanche 12 février 2006

Vrac

  • Une vidéo d'un disque dur en marche... Je savais que les têtes de lecture bougeaient très vite, mais c'est toujours impressionnant à voir !
  • Emuler .Mac... C'est possible. iDisk est remplacer par un (ou plusieurs) partage WebDAV. iCal publie dans aussi dans WebDAV et un script CGI permet de faire fonctionner Backup. Pour arriver à cela, une classique attaque de type "Man in the Middle" a permis de faire croire à Backup qu'il causait à .Mac et a donc permis d'analyser le protocole... Malheureusement, bien que la même attaque ait été réussi contre iSync, personne ne semble avoir réussi à faire le script CGI pour faire fonctionner iSync... Pour l'instant ;-)...
    J'ai bien envie de me monter un .Mac perso avec plein de place et surtout un accès rapide de chez moi (vu que le serveur serait en local...)
  • J'ai trouver le problème de mon proxy RTSP vers HTTP. Premièrement, le protocole RTP possède un en-tête de 12 octets pour chaque paquet émit. Deuxièmement, le buffer que j'utilisais pour stocker les paquets UDP reçu était trop petit... Le script mis à jour est visible ici (téléchargement).
    Il me reste plus qu'à lui faire gérer les connexions multiples et à l'embarquer dans mon routeur Asus WL500g

vendredi 10 février 2006

Petite experimentation autour d'une Freebox

Hier soir, je n'arrivais pas à dormir... J'ai donc décidé de regarder la Freebox sur mon portable, en Wifi depuis mon lit...

Le problème en Wifi, c'est qu'il y a beaucoup trop de paquets perdus... et comme le flux est en UDP, ils ne sont pas retransmis... Donc, ça coupe tout le temps et on a toujours plein de gros carrés.

Je me suis donc mis en tête d'écrire un petit proxy RTSP vers HTTP. Mon postulat de départ est simple. En HTTP, grâce a une liaison TCP, la qualité devrait être meilleur, vu que les paquets perdus sont retransmis (en contrepartie, il faut un buffer pour pouvoir attendre que tout les paquet soient arrivé et dans l'ordre avant de les jouer, mais ça c'est le player qui s'en occupe...). D'autre part, le fait de disposer d'un flux http devrais permettre de lire le flux avec des players qui ne gèrent pas le RTSP (comme QuikTime Player ou des périphériques dédié). Enfin, je me suis dit que l'écriture d'un truc comme ça devait être simple est marrante...

J'ai donc commencé à essayer de le faire en C... Puis je me suis rappelé le nombre de lignes de code qu'il faut aligner avant de pouvoir mettre en place un socket, et aussi que la gestion des string était inexistante... J'ai donc décidé d'essayer d'écrire ça en python... Comme je viens de me mettre à ce langage, je me suis dit que ça pouvait être un bon exercice...

L'algorithme est plutôt simple :
  • On met en place un socket serveur pour attendre une connexion HTTP de la part du client
  • On récupère l'url demandé par le client, et on lui renvois le header de réponse
  • On se connecte à la Freebox, et on demande a jouer le flux demandé (via l'url)
  • On met en place un socket UDP prêt à recevoir le flux de la Freebox
  • Et enfin, on répète toutes les données envoyées sur le port UDP vers le client
Voilà le code que ça donne (Télécharger) :
import socket
import sys

# une petire class de serveur qui me simplifie un petit peu le travail
class server_socket(socket.socket):
	def __init__(self, arg):
		if not type(arg)==tuple:
			self.socket=arg
		else:
			self.socket=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
			self.socket.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
			self.socket.bind(arg)
			self.socket.listen(1)
	
	def accept(self):
		s, addr=self.socket.accept()
		return server_socket(s), addr
	
	def readline(self):
		"""receive and return a complete line"""
		line=""
		while 1:
			char = self.recv(1)
			if not char:
				if line=="":
					return False
				return line
			if char=="\n":
				return line
			if char!="\r":
				line += char
	
	def __getattr__(self, name):
		return getattr(self.socket, name)

# une petite class de client.. la même que pour un serveur, sauf l'initialisation
class client_socket(server_socket):
	def __init__(self, ip, port):
		self.socket=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
		self.socket.connect((ip,port))

# une class qui essaye de comprendre les réponses au requettes RTSP
class basic_rtsp_socket(client_socket):
	def __init__(self, ip, port):
		client_socket.__init__(ip, port)
		self.cseq=1
		
	def request(self, request):
		print "\n".join([">>> %s" % x for x in request.split("\n")])
		self.send(request % self.cseq)
		self.cseq+=1
		l=self.readline()
		print "<<< %s" % l
		(proto, code)=l.split(" ")[0:2]
		if proto[0:4]!="RTSP": raise "Error: not a rtsp response", l
		if code!="200": raise "Error: rtsp error", l
		
		l=self.readline()
		print "<<< %s" % l
		header={}
		while l!="" and l!=None:
			l2=l.split(": ")
			if len(l2)!=2: raise "Incorrect response", l
			header[l2[0]]=l2[1]
			l=self.readline()
			print "<<< %s" % l
		if l==None: raise "rtsp connection closed by foreign host", None
		data=None
		if "Content-length" in header.keys():
			data=read(int(header["Content-length"]))
		return (header, data)


# Début du code

# on met en place un serveur http
http_listen=server_socket(("", 8082))
http_conn, addr = http_listen.accept()
print 'Connected by', addr

data = http_conn.readline()
if not data: raise "no data on http line", None
# on prend la première ligne
(request, url, proto)=data.split(" ")[0:3]
if request!="GET":
	raise "Error : not a get request", data
if proto[0:4]!="HTTP":
	raise "Error : not a http request", data
# on attend la fin de la requette
# soit une ligne vide
# un peu barbare... mais je suis qur qu'il ren a dire d'interressant
l=http_conn.readline()
print "<<< %s" %l
while l!="" and l!=None:
	l=http_conn.readline()
	print "<<< %s" % l
	# parle a ma main !!!
if l==None: raise "http connection closed", None

# on repond le header
http_conn.send("""HTTP/1.0 200 OK
Content-type: application/octet-stream
Cache-Control: no-cache

""")

# on établie la connexion rtsp
rtsp_session=client_socket("mafreebox.freebox.fr", 554)
print "connected to the rtsp session"
# dump du dialogue RTSP entre VLC et la freebox...
(header, data)=rtsp_session.request("""OPTIONS rtsp://mafreebox.freebox.fr/freeboxtv%s RTSP/1.0
CSeq: %s
User-Agent: rtsp2http v0.0.1

""" % (url, "%d"))
(header, data)=rtsp_session.request("""SETUP rtsp://212.27.38.253/freeboxtv%s RTSP/1.0
CSeq: %s
Transport: RTP/AVP;unicast;client_port=1662-1663
User-Agent: rtsp2http v0.0.1

""" % (url, "%d"))
session=header["Session"]
# on se prépare a recevoir les connexion UDP
rtsp_data = socket.socket(socket.AF_INET,socket.SOCK_DGRAM)
rtsp_data.bind(("", 1662))
# Go, go, go
(header, data)=rtsp_session.request("""PLAY rtsp://mafreebox.freebox.fr/freeboxtv%s RTSP/1.0
CSeq: %s
Session: %s
Range: npt=0.000-
User-Agent: rtsp2http v0.0.1

""" % (url, "%d", session))

# on repete tout au client http
ok=True
while ok:
	data, addr=rtsp_data.recvfrom(1024)
	if addr[0]==socket.gethostbyname("mafreebox.freebox.fr"):
		try:
			http_conn.sendall(data)
			# il y a peut etre besoin d'une conversion...
			# mais j'espere pas...
			# a creuser
		except:
			ok=False # une execption... on arrete tout !


# une des connexion a été coupée, on ferme toutes les connexions...
rtsp_session.request("""TEARDOWN rtsp://mafreebox.freebox.fr/freeboxtv%s RTSP/1.0
CSeq: %s
Session: %s
User-Agent: rtsp2http v0.0.1

""" % (url, "%d", session))
rtsp_session.close()
rtsp_data.close()
http_listen.close()
http_conn.close()

Pour l'instant, VLC arrive à se connecter, le proxy se connecte à la Freebox et commence à répéter le flux... mais rien a ne s'affiche à l'écran...

Bon il était déjà 2h30 et maintenant, j’avais vraiment envie de dormir… Mission réussie… Je suis aller me coucher ;-)

J'ai deux piste à creuser pour essayer de faire marcher ça : Vérifier que toutes les données sont bien retransmises (problème de taille de buffer, ou de vitesse (paquets dropé) par exemple), ou vérifier si je peux bien renvoyer le flux brute de cette façon, et s'il ne faut pas le convertir et el remettre en forme...

Affaire à suivre ;-)

Update 12/02/2006 : J'ai débugé le script.
Update 21/02/2006 : Quelques modifications.

Le traitement graphique accéléré 3D

Sur la mailing liste de Rotomalug, Aurélien Moreau se demande quel est l'intérêt du passage à la 3D pour un desktop... Il vrai qu'a première vue ça n'apporte rien... C'est pour cela que je pense qu'un petit éclaircissement est nécessaire...

Le problème, c'est qu'actuellement, les cartes vidéo n'offre plus aucune accélération matérielle en 2D... Si tu veux affiche une fenêtre en 2D, il te faut compter uniquement sur le CPU... Et le CPU, il a pas que ça a faire...

A coté de la partie 2D dans une carte vidéo, il y a la 3D... La 3D est beaucoup plus rapide que la 2D, même pour faire de la 2D... De plus, la 3D est en constante évolution... Elle prend plus de 95% du silicium d'une puce de carte vidéo...
Donc, l'idée est de codé dans la partie 3D (via de l'open GL) toutes les fonctions graphiques... Que ce soit la gestion des fenêtres ou les primitives de dessin...

La carte vidéo dessine beaucoup plus vite que le CPU. Par exemple, appliquer un flou sur une image dans Gimp prend quelques secondes (voire minutes sur des effets plus complexes)... La plupart des effets de Gimp peuvent être fait instantanément (genre à 60 images traitées par seconde) via la carte vidéo... Ce qui veux dire aussi que de tels effets peuvent aussi être appliqué en temps réel sur chaque images d’une vidéo… Toutes les machines vendues depuis 4 ans ont des cartes capables de telles prouesses mais elles sont inutilisées... Pourquoi ne pas les utiliser ?

D’autre part, certains prédisent même que la partie 2D des cartes vidéo va disparaître dans un futur proche (au moins une fois que les PC se seront débarrassés de leur BIOS (qui utilise toujours le mode 2D) pour booter le PC) au profit de l’EFI).

MacOSX (oui, je radote encore) implémente déjà ces technologies… Pour bien comprendre de quoi il retourne, je vous invite a lire l’excellent article (et aussi la page suivante) de ARS Technica présentant l’architecture mise en jeu… Ce qu’ils disent la s’appliquera bientôt aussi a Linux. Je peux dire que c’est une véritable avancée en matière de performance, même sur une petite machine (Je parle de mon PowerBook 1.3Ghz)… Donc oui, je suis convaincu que ça apporte vraiment beaucoup !

Pour info :
Technologies :MacOSXLinux
Gestion des fenètres : Quartz Extreme 2DXgl + Luminocity
Dessin vectoriel : QuartzCairo
Accélération du traitement graphique (voir vidéo) : Core Image (Core Video)Rien

mercredi 8 février 2006

Xyle scope en Français

Je viens d'effectuer, avec l'aide de Jürgen Schweizer, la traduction en Français de Xyle scope...
Xyle scope est un outil permettant de débugger et d'analyser les feuilles de styles (CSS) pour les pages Web... J'en avais déjà parlé dans un billet précédent.
La nouvelle version de Xyle scope est donc désormais disponible en Français. Il me reste encore l'aide à traduire pour une prochaine version...

Cette traduction n'est pas figée dans le marbre. Il est possible que certain texte ne soit pas forcément très clair... Ce n'est pas facile de toujours trouver le bon mot (J'ai appris grâce a cette traduction, qu'il est plus facile de traduire des phrases que des mots ou des bouts de phrases)... Bref, si vous avez des commentaires, ou que vous trouvez des fautes d'orthographe, n'hésitez pas à le souligner avec vigueur dans un commentaire à ce billet ou via un petit mail...

Enfin, Xyle scope n'est pas un logiciel libre, mais je pense qu'il est important de supporter les développeurs indépendant qui, comme Jürgen, mettent toute leur énergie pour faire des logiciels performants et innovants. Un bon logiciel a parfois un prix (en plus, là, il est vraiment pas élevé !)...

Essayez Xyle scope

samedi 4 février 2006

Vrac

J'ai passé la majeure partie de ce samedi après midi à me documenter sur les bindings Cocoa.... Au terme de cette lecture, je ne regrette qu'une chose, que cette technologie ne soit pas disponible dans GNUStep... ;-)
  • Le design du Web2.0... Dégradé, bords arrondis, grandes polices sans serif... Le bougre, il a raison, c'est vraiment à la mode en ce moment !
  • Le point sur l'affichage sous Linux (ou en anglais, The State of Linux Graphics, car certaines phrases ne sont pas vraiment claires dans la traduction) est plus une liste exhaustive des défauts de X11 de nos jours ! L'auteur explique notamment que les cartes graphiques modernes sont plus rapides en traitement 3D qu'en 2D. Sa proposition est de créer un serveur graphique basé sur OpenGL. Il a d'ailleurs commencé avec Xgl... Malheureusement, ce projet ne semble pas encore utilisable.
    Il propose de revoir complètement l'architecture graphique de Linux pour la rendre plus puissante, maintenable et sécurisée. Selon lui, les drivers vidéo devrait être intégrées au Kernel au lieu d'être en espace utilisateur dans X11 (ça me semble ahurissant que ce ne soit pas le cas !). Le Kernel devrais fournir une API uniformisé et stable. Toutes les fonctions de cette API qui ne sont pas disponibles sur la carte graphique sont faites en logiciel. L'API proposé (mais il explique qu'il pourrais y en avoir d'autre) est l'OpenGL avec un mapage des fonctions non matérielles vers Mesa... De plus il voudrait que le serveur X utilise les fonction HotPlug fournit par le Kernel...
    Il est vrai que niveau affichage, actuellement, Linux ne tiens pas la route face à MacOSX ou le futur Windows Vista...
    J'en ai rêvé toutes la nuit, d'un bureau Linux accéléré OpenGL et supportant le HotPlug (branchement à chaud des périphériques d'entrées bien sur, mais aussi des écrans, changement de résolutions à la volée, etc...).
  • Et pour vous mettre l'eau a la bouche, voici ce que ça pourrais donner : Preview des wobbling windows. Ceux qui disent que ça ne sert à rien n'ont rien compris... Ici ce qui est intéressant, ce n'est pas de déformer les fenêtres, c'est plutôt d'avoir un affichage capable de composer les fenêtres en utilisant le GPU au lieu de la carte graphique, ou encore de pouvoir utiliser l'accélération OpenGL pour des bibliothèques de dessin vectorielle comme Cairo... Bref ce que fait déjà Quartz (même si une grande partie de l'interface est en fait composé de Bitmap) et ce que promet Vista... Avec les résolutions des écrans qui augmentent sans cesse (1920x1200 sur un 15" !!!), il va être temps de quitter le monde du bitmap pour passer au vectoriel. Bref il est temps que l'unité de mesure pour l'affichage ne soit plus le pixel, mais le centimètre !!!


Bon j'arrête un peu de rêver et je retourne bosser !!!

Rendre la Freebox vraiment multiposte

A Noël dernier, Free a lancé une nouvelle fonctionnalité sur la Freebox. Elle peut désormais streamer les chaînes de TV directement sur le LAN.
Cela permet donc de regarder la TV sur ses PC ;-) J'attendais cette fonctionnalité depuis longtemps. Je pensais que ça ne se ferait jamais car je sais que les chaînes et les ayant droits sont en général assez frileux avec les nouvelles technologies (qui a dit piratage)...

Comme a son habitude, Free a fait les choses bien... Plutôt que de nous mettre, comme c'est à la mode un seul flux crypté avec des DRMs et un protocole propriétaire, ils ont utilisé un protocole standard, le RTSP. Ce protocole est normalement compris par tous les bons lecteurs vidéo comme VLC et MPlayer. De plus ils n'ont pas limité a un seul flux... Dans la pratique, on peut regarder autant de flux que l'on peux en faire passer dans la liaison ADSL (voir dans le LAN si vous êtes en Wifi ou encore en Ethernet 10MBps (Freebox v3)). En bref, on peut regarder sans problème 2 ou 3 flux simultanément. Un miracle !!!

Free a appelé cette fonctionnalité Freebox Multiposte... Mais en pratique, c'est bien souvent monoposte... Je m'explique.
Le protocole RTSP a un fonctionnement particulier, assez proche de celui du FTP. Quand on veut regarder un flux, VLC ouvre une connexion TCP vers le port RTSP de la Freebox. Ce canal permet de mettre en place les paramètres de la diffusion. Le flux vidéo lui passe par une liaison en UDP émise par la Freebox. Le port de destination de cette transmission en UDP est normalement tiré au sort par VLC en envoyé vers la Freebox... Dans une configuration monoposte, ça marche très bien... Mais dès que l'on met un routeur (NAT) entre les deux, le flux UDP ne peut arriver jusqu’à l'ordinateur qui la demandé...
La solution proposé par Free est une version modifié de VLC qui restreint la plage de port UDP qu'elle va utiliser, tout en routant cette page de port (DNAT) vers le PC. Le routage étant statique, on retombe dans une configuration monoposte.

La solution est d'avoir un routeur firewall intelligent qui soit capable d'écouter les transactions RTSP et d'ouvrir le port demandé de façon dynamique. Cela existe déjà pour le FTP par exemple. Sous Linux, il existe une série de modules iptables appelé conntrack (Connexion tracking, soit Suivit de connexion), chargé justement de faire cela...
En fouillant dans les sources du kernel, on trouve bien une série de modules de conntrack pour le FTP ou IRC... Mais rien pour le RTSP...
Il existe en fait un tel module sur le site d'iptables, mais il n'est pas intégré au kernel, il faut donc le patcher...
J'ai décidé de le faire pour une distribution OpenWRT, afin de pouvoir continuer à utiliser mon ASUS WL500g comme routeur, et éviter de devoir mettre un PC dans le salon...

Voici en gros comme je m'y suis pris :
  • J'ai téléchargé les sources de la distribution OpenWRT.
  • J'ai patché les sources avec ce patch.
    wget http://downloads.openwrt.org/whiterussian/rc4/whiterussian_rc4.tar.bz2
    tar jxvf whiterussian_rc4.tar.bz2
    wget http://perso.ens-lyon.fr/benoit.boissinot/rtsp.diff
    cd openwrt
    patch -p0 <../rtsp.diff
    make menuconfig
    
    J'ai activé, notamment, les modules iptables supplémentaires (iptables-extra)... Ensuite, j'ai lancé la compilation :
    make
    
    Le Makefile se charge alors télécharger, patcher, compiler, packager tout... C'est magique...
    La compilation finie, il n'y a plus qu'a flasher le router avec l'image correspondant à son modèle (présente dans le répertoire bin)... Le répertoire bin/package contient les packages (on s'en serait douté ;-) ). Il faut juste les copier sur un serveur web...
  • Une fois OpenWRT booté, et configuré selon les besoins de votre réseau, il faut installer le paquet kmod-ipt-nat-extra et lancer les modules.
    Après avoir modifier votre /etc/ipkg.conf pour ajouter l'url du serveur ou vous avez ranger les paquets :
    ipkg install kmod-ipt-nat-extra
    modprobe iptables-conntrack-rtsp
    modprobe iptables-nat-rtsp
    echo "ip_conntrack_rtsp" >> /etc/modules
    echo "ip_conntrack_ftp" >> /etc/modules
    echo "ip_nat_rtsp" >> /etc/modules
    echo "ip_nat_ftp" >> /etc/modules
    
Il ne vous reste plus qu'a profiter de la TV sur tous les ordinateurs de votre maison !!!
Magique !

Update 26/02/2006 : J'ai mis en lignes les binaires que j'ai généré.

vendredi 3 février 2006

Fonds d'écran

Pour égayer un peu mes nombreux écrans, je fais chercher mes fonds d'écran sur Mandolux... En dépit d'une ergonomie plutot passable, je trouve que ce site propose des fonds d'écrans de toute beauté, dans toutes les résolutions (jusqu'au 30"), et pour toutes les configurations d'écrans (jusqu'au triple écran)...

A conserver dans les bookmarks ;-)

C'était l'info inutile du jour !