- Polices STIX Il aura fallu dix ans pour aboutir à la première version bêta des polices scientifiques libres STIX en UTF-8. Cela permet notamment de disposer de 8000 représentations graphiques (glyphes), utilisables pour MathML afin de représenter des formules mathématiques ou de physique. Le consortium STIX est constitué de plusieurs entités connues dans le milieu des publications scientifiques : l'American Institute of Physics, l'ACS, l'AMS, IEEE, Elsevier, l'APS.
- Sources de Multics Multics, l'ancêtre d'Unix, OS désormais abandonné dont le dernier serveur en production a été éteint en 2000, a vu ses sources récemment publiées. Écrit en langage PL/1 en 1965 par le MIT, les laboratoires Bell et General Electric, il fut ensuite commercialisé par Honeywell dans les années 70, qui le revendit à Bull au milieu des années 80. Le site Multicians retrace l'histoire de ce système. Pour les plus courageux qui souhaiteraient compiler les sources, il existe un front-end PL/1 à Gcc: pl1gcc.
- Skype ajoute la vidéo sous Linux Skype, le logiciel P2P ultra-proprio de VoIP, a été publié en version 2.0 bêta sous Linux, et ajoute la vidéo, 2 ans après la version Windows.
Merci à Maclag pour son journal sur STIX.
Merci à fleny68 pour son journal sur Multics.
Merci à therealnicoco pour son journal sur cette bêta de skype intégrant la vidéo. La vidéo sous Linux est bien évidemment déjà présente sous des logiciels libres reposant sur des standards ouverts tels que Ekiga.
Aller plus loin
- Polices scientifiques STIX (3 clics)
- Code source de Multics (1 clic)
- Skype ajoute la vidéo sous Linux (3 clics)
# Multics et pl1gcc
Posté par Erwan Hamon . Évalué à 5.
- pl1gcc, d'après son site, n'a pas atteind le stade de produire un exécutable.
- Multics était, semble-t'il, prévu pour fonctionner sur des ordinateurs disparus à architecture 36 bits. Faut-il commencer par écrire un émulateur ?
A voir si une équipe va relever le défi pour la beauté du geste...
[^] # Re: Multics et pl1gcc
Posté par Francois Revol (site web personnel) . Évalué à 5.
Autre point, les sources sont en ligne, mais dans des pages web, pas accessible sous forme d'archive, donc pas vraiment compilables directement.
Ca méritait pas une news entière ça quand même ??
[^] # Re: Multics et pl1gcc
Posté par Nÿco (site web personnel) . Évalué à 7.
Sans doute... mais elle n'est pas tombée du ciel... ;-)
CON-TRI-BUEZ ! svp... :-p
[^] # Re: Multics et pl1gcc
Posté par patrick_g (site web personnel) . Évalué à 4.
[^] # Re: Multics et pl1gcc
Posté par BAud (site web personnel) . Évalué à 4.
[^] # Re: Multics et pl1gcc
Posté par Guillaume Knispel . Évalué à 2.
[^] # Re: Multics et pl1gcc
Posté par Francois Revol (site web personnel) . Évalué à 0.
# Video sous Linux dans Skype
Posté par rhizome . Évalué à 1.
Sinon la vidéo sous Ekiga ça marche derrière du NAT maintenant ?
[^] # Re: Video sous Linux dans Skype
Posté par BAud (site web personnel) . Évalué à 2.
juste tu essaies hein, cela reste du logiciel libre, qu'est-ce-qui t'empêche d'essayer et de nous faire un petit retour d'expérience ? :)
[^] # Re: Video sous Linux dans Skype
Posté par dawar (site web personnel) . Évalué à 3.
D'après une copine, la beta de Skype, ben la video marche 1 minute si t'as de la chance, et ça plante lamentablement.
[^] # Re: Video sous Linux dans Skype
Posté par rhizome . Évalué à 1.
Voila, c'est tout le problème. Il semble que l'utilisation du protocole STUN permet d'éviter toute configuration spécifique sur le routeur NAT. Sur http://ekiga.org/index.php?rub=3&pos=0&faqpage=x161.(...) on peut lire à peu près ceci : La première chose à faire est de lancer l'assistant de configuration NAT. Si celui-ci indique "Cone NAT" ou "Port Restricted NAT", vous avez just à répondre "oui" au dialogue proposant l'activation sur support STUN.
[^] # Re: Video sous Linux dans Skype
Posté par dawar (site web personnel) . Évalué à 2.
[^] # Re: Video sous Linux dans Skype
Posté par Yannick . Évalué à 7.
Si les NAT avaient tous le même comportement, il n'y aurait pas de problème pour les passer. Or les NAT sont implémentés selon le bon vouloir de leurs constructeurs. Une nomenclature a été mise au point en vu de les passer justement, et il se trouve que les NAT dit "symétriques" sont infranchissables sans avoir un relai extérieur. Skype les passe probablement et se faisant relayer par d'autres clients skype qui eux ne sont pas derrière des NAT (des super nodes en somme).
Fort heureusement l'IETF est consciente du problème et travaille à le résoudre en tentant de normaliser le comportement des NAT grâce au gropue BEHAVE: http://www.ietf.org/html.charters/behave-charter.html
Le méchanisme STUN, qu'utilise Ekiga est issu de ce groupe de travail et permet de passer la majorité des NAT. Un autre méchanisme, dit ICE, étend STUN avec la mise en place de relais (méchanisme dit TURN) et un algorithme pour décider de la meilleure route à suivre, mais il faut donc mettre en place des serveurs qui vont relayer les communications (donc il faut les ressources nécessaire en terme de bande passante, de coûts et cela induit de la latence supplémentaire). L'autre voie suivit par ce groupe de travail est de normaliser les NAT ce qui me semble la bonne solution.
À terme la situation va donc s'améliorer et le besoin d'astuces comme Skype en utilise se fera moins sentir et disparaîtra, ce qui est une bonne nouvelle pour tous les logiciels qui font du p2p.
Pour ce qui est de la qualité de la vidéo, cela est lié à la qualité de la webcam, et sous GNU/Linux on a aujourd'hui de très bonnes webcams compatibles, notamment grâce à la norme industrielle UVC video (par exemple la Logitech Quickcam Pro 9000 et la Creative Live! Cam Optia AF) ou encore la Philips SPC900NC qui utilise le driver pwc. C'est aussi très lié au codec vidéo utilisé. Ekiga en version stable aujourd'hui utilise le codec H.261 qui est loin de ce qui se fait de mieux en la matière. Grâce à un nouveau contributeur, la version de développement a maintenant beaucoup de nouveaux codecs vidéo: H.263+, Theora et surtout l'excellent H.264 qui est ce qu'utilise xchat sous Mac OS. Ils seront disponible dans la version 3.0 d'Ekiga et on n'aura rien à envier à Skype sur ce point (et son codec VP7) car il semble qu'H.264 soit meilleur que ce qu'utilise Skype.
Roadmap d'Ekiga:
http://wiki.ekiga.org/index.php/Roadmap_to_3.00
Cordialement,
Yannick
[^] # Re: Video sous Linux dans Skype
Posté par Yannick . Évalué à 2.
[^] # Re: Video sous Linux dans Skype
Posté par Antoine . Évalué à 4.
Ce n'est pas qu'ils sont réellement infranchissables, c'est que le couple (IP, port) public change pour chaque pair contacté en UDP. Donc il est impossible pour un noeud (terminologie P2P) présent derrière un NAT symétrique de renseigner a priori ses pairs sur la façon de le contacter. S'il était possible pour ce noeud d'interroger le NAT pour déterminer à l'avance le couple (IP, port) public d'un futur mapping, le problème serait résolu. Si je ne me trompe, c'est à quoi sert la norme uPNP créée/soutenue par Microsoft.
Par ailleurs il faut savoir que la majorité des équipements utilisés par les particuliers (machin-box et compagnie) ne sont pas de type "NAT symétrique" mais "full cone" ou "restricted cone". C'est-à-dire que le couple (IP, port) public en UDP ne dépend que du couple (IP, port) privé correspondant et non du pair avec lequel on échange des messages. Dans ce cas on peut communiquer le couple (IP, port) à ses pairs après l'avoir déterminé grâce à un serveur fixe prédéfini.
Un problème plus coriace se pose quand le noeud se trouve derrière plusieurs NATs en cascade (c'est le cas si on utilise un modem-routeur personnel derrière un FAI qui attribue des IP privées à ses abonnés... il paraît que c'est le cas dans certains pays d'Asie).
[^] # Re: Video sous Linux dans Skype
Posté par rhizome . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.